home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
BBS Toolkit
/
BBS Toolkit.iso
/
doors_1
/
echo311.zip
/
ECHODOR.TXT
< prev
next >
Wrap
Text File
|
1992-03-16
|
204KB
|
6,810 lines
****** ****** * * ***** ***** ***** *****
* * * * * * * * * * * *
**** * ******* * * * * * * ******
* * * * * * * * * * * *
* * * * * * * * * * * *
****** ****** * * ***** ***** ***** * *
EchoDor version 3.11
Original Program By Scott Baker
Modifications by Robert McCullough
Documentation by Jonathan Woods
If you should happen to find this program useful,
Please send a contribution to:
Robert McCullough
P.O. Box 101095
Nashville, TN 37224
Voice Phone 615 256-2444
For the latest version of EchoDor, you may call
The NEW WorkBench BBS (9600/Hst)
BBS Phone 615 256-2211
FidoNet Node 1:116/1000.0
RBBS Net 8:967/1.0
File Requestable as ECHODOR
EchoDor Version 3.11
3/16/92
Introduction 1
Installation 2
DoorDriv.Ctl parameter file 5
Multiple DoorDriv.Ctl files 5
Parameters 6
Color Table 12
Special instructions 13
PC Board 14 13
PC Board 12 13
Opus 1.7x 13
GT PowerComm 13
Genesis Deluxe 13
LINE-A operation 13
LINE-B operation 14
ECHODOR.CTL parameter file 15
Display file naming 15
Parameters 16
Color Table 32
SYSOP setup 33
Pack Mail / Compress / Download Setup 34
Basic Setup 34
Compressing Mail 35
Downloading Mail 36
Multiple Node Setup 38
The Common Directory Method 39
Multiple Directory Method 42
Multiple Net Setup 45
Purging & Renumbering Areas 47
The Three Step Method 47
EDorPurg 49
Setup 49
EDorPurg Parameters 51
Operation 53
Recovery Method 54
FastLink 55
Parameters 55
Operation 57
Page i
EchoDor Version 3.11
3/16/92
EchoDor Operation 59
Menu Commands 59
Reading messages 60
Entering messages 62
Line Editor 62
Full Screen Editor 64
Insert Mode versus Over type Mode 66
Keyboard emulation 66
Visual Quote 67
Using EchoDor Locally 68
Special local keys 69
Message Header Description 70
How do file-requests work? 72
File-attaches 74
Auto Messages 76
General information 77
EchoUser Program 78
User File Records 78
Default User & Maintenance Record 78
User Records 79
Remote Operation 80
Using SCANMRG 81
The EchoDor Nodelist compiler 82
How it works 82
The Control file 82
Running EchoNLCP 83
EchoNLRD node list reader 84
Opus 1.1x Converter (OPUSCNVT) 85
Support for EchoDor 86
Revision History 87
3.11 revisions 87
Page ii
EchoDor Version 3.11
3/16/92
3.10a revisions (we didn't release a 3.10): 90
3.09 revisions: 92
3.08 revisions: 95
Run Time Errors 97
Plans for next version 103
Registration 104
Disclaimer 105
Guarantee 106
Page iii
EchoDor Version 3.11
3/16/92
Introduction
EchoDor is a full featured echo mail conference processor that incorporates
features found in many door programs, and bulletin board systems. The Echo
mail community has for some time been lacking a really good echo mail door.
It is due to this lack that EchoDor was created.
EchoDor may be used on several BBS systems. It is configurable to run
under RBBS-PC Ver CPC 15.1 through 17.2, PCBOARD 14.1, and Quickbbs. The
difference between these BBS systems is the way they handle passing
information to a Door program. RBBS 15.1 puts the information in the
first record of the message file. RBBS 16.1+ creates a small text file
called DORINFOx.DEF. (the 'x' being the node number that called the
door program). PCBOARD creates a random access file called PCBOARD.SYS.
Quick BBS passes all the parameters on the command line that calls the
door.
The information that is passed includes the Users Name, the Communications
Port, the baud rate, the graphics type selected, the time remaining, and
the sysop name. This information is used by EchoDor to monitor the carrier
of the appropriate port, and to control various other functions of EchoDor.
If you don't have echo mail currently operating, you probably don't have a
need for this program. If you are adding echo mail to your system, and
haven't completed installing it yet, STOP. Go back to the echo mail
programs, and get that working FIRST! You should set up echo mail to work
in a set of subdirectories like FIDO, OPUS, and the rest of the net mail
bulletin boards. If you are using RBBS, DO NOT USE RBBSMAIL! RBBSMAIL puts
the echo mail messages in your RBBS conference files! EchoDor can't
support this feature!
If you are using PC Board or QuickBBS, the installation procedures are the
same as for RBBS.
Thus far PCBOARD does not support a net mail front end processor due to the
fact that it does not allow parameters to be passed on the command line.
To support echo mail using PCBOARD, BinkleyTerm has to be run in the "MAIL"
mode as an event from PCBOARD each evening. Due to this, PCBOARD sysops
cannot support Crash mail. Also, PCBOARD does not provide EchoDor will
security levels; therefor, security level access control will not work.
EchoDor provides a "default" security for all users of 50 when running with
PCBOARD.
Page 1
EchoDor Version 3.11
3/16/92
Installation
If you already have net mail running, the installation will be very simple.
If you don't run net mail, some explanation is in order.
EchoDor uses FIDO type messages. IE: each message is a separate file
(1.MSG, 2.MSG etc..). The messages in each area (Conference/Forum) are
stored in their own Subdirectory. EG:
C:\------ BBS
|
+--- MAIL ------- PRIVATE
|
+--- BAD_MSGS
|
+--- HUMOR
|
+--- RBBS-PC
|
+--- CHATTER
|
+--- POLITICS
You need to get echo mail processor to move all your incoming messages to
subdirectories like these. Examples of programs that do this are ConfMail,
QM (or QMail), or TossScan.
Set up this subdirectory structure BEFORE proceeding to the next section!
You must also set up a fossil for EchoDor to use to communicate with the
modem. A number of fossil programs are available including X00, BNU, or
OPUS!COM. Get one of these if your not already using one and get it
installed.
Then:
Create a directory to hold all the files in the EchoDor archive.
Unpack the archive into the directory.
Edit the file DoorDriv.Ctl to reflect the information about your system.
Follow the comments contained in the file.
Enter your first name as SYSOPFIRST name.
Enter your last name as SYSOPLAST name.
Enter your BBS name as BBSNAME name.
Select your BBS type as BBSTYPE. If your BBS type is not listed, you may
have to run EchoDor with some converter program.
Place the drive and directory of your BBS into the line marked BBSPATH.
This tells EchoDor where to get the door information file.
Page 2
EchoDor Version 3.11
3/16/92
If you run a "locked baud", uncomment the line BAUD and set your baud rate.
This will override the baud specified in the door drop file.
We'll leave the rest of the entries as they are for now. See the following
sections for a complete list of parameters and their uses.
Edit the file "ECHODOR.CTL" to reflect information about the echos you
intend to carry. Follow the comments in the file.
Enter your own zone, net and node numbers.
Enter your name as SYSOPNAME name.
Enter your name as COMMENTNAME name.
Edit the 2 tables, AREATABLE and AREADESC to your own echo mail areas. The
comments in the file should explain how to do this. See also the section
titled ECHODOR.CTL parameter file.
Now run:
EchoUtil /USERFILE
EchoUtil will ask if you want Hot keys on as the default. Answer either Y
or N. EchoUtil will create the user file.
Run the CheckOut program. This program checks a lot of the entries and
will help you resolve a number of problems. If Checkout generates too much
output for your screen, you can redirect the output to your printer by
using the command:
Checkout > PRN
Set up a door batch file to something like the following:
rem
rem switch to the EchoDor directory and start
rem EchoDor
rem
CD \EchoDor
rem
rem now run EchoDor and pass it the node number
rem in this example the node number is passed as
rem the first parameter of the batch file. If you
rem only run a single node, change the %1 to 1.
rem
rem | this is the parameter which is the port
rem | number. All other information will come
rem | from the bbs door file.
rem v
ECHODOR %1
rem
CD \rbbs
rbbs
(SEE the Example Batch file called ECHODOR.BAT)
Page 3
EchoDor Version 3.11
3/16/92
Note:
make sure that your batch file copies dorinfo*.def
to the EchoDor directory. This is a very important
file.
Test the door in local mode with "ECHODOR /L" to make sure it is working.
Page 4
EchoDor Version 3.11
3/16/92
DoorDriv.Ctl parameter file
The DoorDriv.Ctl file controls the door's interaction with the
communication port and provides information about the BBS type that is
calling the door. This file is required and must be in the default
directory when the door program is started. The DoorDriv.Ctl example file
contains a number of comments which should help you in editing this file.
This chapter contains a list of all the parameters for DoorDriv.Ctl and
their use.
Multiple DoorDriv.Ctl files
It is sometimes necessary to have multiple DoorDriv.Ctl file when running a
multiple line system. One modem might be one speed or different monitors
might be used on different nodes. Door Driver now supports multiple
control files.
The specific file selected depends on the "node" number specified when
starting the door. Local operation always uses "node" zero (0). The name
of the file comes from replacing the last character of the file name
(before the period) with the node number. If that file dose not exist,
Door Driver will then look for the base file (DoorDriv.Ctl). The different
control files might be named:
DoorDriv.Ctl < base file used as default >
DoorDri0.Ctl < used for node 0 (local) >
DoorDri1.Ctl < used for node 1 >
DoorDri2.Ctl < used for node 2 >
.
.
DoorDriX.Ctl < X = node number >
Up to nine nodes plus local is supported. Remember that some doors change
the name of the Door Driver control file. The naming would be altered to
use the new base name.
Page 5
EchoDor Version 3.11
3/16/92
Parameters
BACKGROUND
This parameter specifies the default background color used by the door
program. See the list of available colors at the end of this section
for the color numbers that can be used. Only the numbers 0-7 can be
used here. The format of this command is:
BACKGROUND n
Where n is the color number desired as the default background
color for the door. Note that some doors may not honor this
parameter and use other colors.
BAUD
This parameter is used to set the baud rate of the door if you use a
system that runs a locked baud. The format of this parameter is:
BAUD xxxxx
The following fixed BAUD rates are supported:
300, 600, 1200, 2400, 4800, 9600, 19200, 38400
If this parameter is not used the baud rate used will be the baud
in the door control file written by the BBS system.
BBSNAME
This parameter is the name of the BBS that you want to have displayed
to the user when the door closes. This parameter is required. The
format of this line should be:
BBSNAME name of my board
DO NOT put quotes around the name of your board or they'll show,
just enter the name as you would type it.
BBSPATH
Most doors require you to copy your door information file (written by
your BBS) into the directory where the door resides. By setting
BBSPATH, you instruct this door to read the door information file from
the specified drive and directory. This avoids you having to copy the
file and reduces start up time.
This parameter is optional. If it is not specified, the door will
look for the door information file in the current directory.
BBSTYPE
Page 6
EchoDor Version 3.11
3/16/92
Most doors will only run with a specific type of BBS. This door will
run with a number of different types of BBS systems. To tell the door
the type of BBS you have you must set the BBS type. This is a
required parameter. The format of this parameter is:
BBSTYPE type
The type should be replaced with one of the following:
RBBS - for RBBS-PC 16.1+ (DORINFOx.DEF file)
RA - for Remote Access (DORINFOx.DEF file)
QUICK - for QuickBBS (DORINFO1.DEF file)
PCB12 - for PC-Board 12.
PCB14 - for PC-Board 14.
WWIV - WWIV BBS (CHAIN.TXT file)
PHOENIX - Phoenix BBS (INFO.BBS)
WILDCAT - for WildCat! BBS (CALLINFO.BBS file)
OPUS17x - for Opus 1.7x (LASTUS##.DAT file)
GT - for GT PowerComm (GTUSER.BBS file)
GENESIS - for Genesis Deluxe (CALLINFO.BBS file)
WC3.0 - for WildCat! BBS (DOOR.SYS file)
GAP - for GAP bbs (DOOR.SYS file)
LINE-A - command line parameters (see below)
LINE-B - command line parameters (see below)
CHATSYSOPCOLOR
This parameter specifies the color to use for the SYSOP when in chat
mode. The format of the command is:
CHATSYSOPCOLOR nn
Where nn is the color number desired for the color to use for
text typed by the SYSOP during chat mode. See the list of
available colors at the end of this section. The default for
this parameter is "yellow" (14).
CHATUSERCOLOR
This parameter specifies the color to use for the USER when in chat
mode. The format of the command is:
CHATUSERCOLOR nn
Where nn is the color number desired for the color to use for the
text typed by the USER during chat mode. See the list of
available colors at the end of this section. The default for
this parameter is "light blue" (9).
COLOR1
Some BBS systems set the color indicator differently than the door
expects. If your users do not get color when they should, try
including this parameter in the DoorDriv.Ctl file.
Page 7
EchoDor Version 3.11
3/16/92
COMPORT
Some BBS systems do not write the communications port number to the
door control file. One example of this is PC-Board version 12. If
you run a BBS of this type, you must tell the door which
communications port to use by using this parameter. The format of
this parameter is:
COMPORT x
Where x is a 1, 2 .... maximum port.
DIRECTVIDEO
The door uses BIOS type writes to display information on the local
screen. This mode is best for people that run DV. If you want faster
screen writes, include the DIRECTVIDEO parameter and the system will
use direct screen writes.
FOREGROUND
This parameter specifies the default foreground color used by the door
program. See the list of available colors at the end of this section
for the color numbers that can be used. The format of this command
is:
FOREGROUND nn
Where nn is the color number desired as the default foreground
color for the door. Note that some doors may not honor this
parameter and use other colors.
HILIGHTCOLOR
This parameter specifies the color to be used for highlight. See the
list of available colors at the end of this section for the color
numbers that can be used. The format for this command is:
HILIGHTCOLOR nn
Where nn is the color number desired as the default foreground
highlight color for the door. Note that some doors may override
this parameter.
IDLETIME nn
This specified the maximum idle time in seconds between keystrokes.
When 2/3rds of the idle time has passed, the program will issue a
beep. When the total time lapses and no keystroke has been make, the
door will exit.
This may be disabled by setting IDLETIME 00.
MAXTIME nn
Page 8
EchoDor Version 3.11
3/16/92
This parameter is used to specify the maximum time the user is allowed
in the door. Some BBS systems require this parameter because the time
remaining is not passed. GT is an example of this.
In boards where the maximum time is passed, if the user has more time
available than the value specified here, the users time for the door
will be reduced to the specified MAXTIME. Maximum time is specified
in minutes.
This may be disabled by setting MAXTIME 00.
MINTIME nn
This parameter allows you to set the minimum amount of time the user
must have remaining to be able to use the door. If the total time
remaining is less than the time specified, the user will be told that
he doesn't have enough time and the door will exit. Minimum time is
specified in minutes.
This may be disabled by setting MINTIME 00.
MONO
This parameter if present will disable color on the local display.
This is required if you run a monochrome monitor.
NOTIME filename
This parameter if present will allow you to tell the door to display a
file when the user runs out of time.
PROMPTCOLOR c1 c2 c3
This parameter defines the colors used for some requests made by the
door. All three items are color numbers from the list below. The
first color number (c1) is the foreground color of the input field.
The second color number (c2) is the background color of the input
field. The third color number (c3) is the foreground color number of
the "Prompt Text".
QUIET
This parameter will prevent ^G (bell) characters from ringing the bell
on the local system.
Page 9
EchoDor Version 3.11
3/16/92
STATFORE
This parameter is the foreground color of the status line. If the
status line is off (see the STATUS parameter) this command has no
effect. Refer to the list of colors at the end of this section for
the color numbers that can be used. The format of this command is:
STATFORE nn
Where nn is the color number desired for the status line
foreground color.
STATBACK
This parameter is the background color of the status line. If the
status line is off (see the STATUS parameter) this command has no
effect. Refer to the list of colors at the end of this section for
the color numbers that can be used. The format of this command is:
STATBACK nn
Where nn is the color number desired for the status line
background color.
STATUS
This parameter turns the status line on the local side on and off. I
suggest you try it turned on. If the status line causes problems then
turn it off. The format of the command is:
STATUS ON
or
STATUS OFF
Note: Some doors disable the status line when running in
Local Mode.
SWAPFILENAME
If it is desirable to have the door swap itself out of memory when
shelling to DOS, this parameter must be specified. If the parameter
is not specified, the door will remain in memory when a "shell to dos"
is requested. If the parameter is specified AND there is available
EMS to use, the door will be swapped to EMS in place of disk. The
format of this parameter is:
SWAPFILENAME <filename>
Where <filename> is a drive/path/name of the file to be used by
the door when swapping itself out of memory. If the path is not
specified, the default start up path for the door will be used.
If the <name> part of the <filename> contains a pound symbol (#),
the pound symbol will be replaced by the node number of the
Page 10
EchoDor Version 3.11
3/16/92
running door. DO NOT ALLOW two copies of the door to use the
same swap file!! .
SYSOPFIRST
This is the first name of the SYSOP. This parameter is required and
should be entered as:
SYSOPFIRST Name
SYSOPLAST
This is the last name of the SYSOP. This parameter is required and
should be entered as:
SYSOPLAST Name
Page 11
EchoDor Version 3.11
3/16/92
Color Table
The follow colors may be used for both background colors and foreground
colors:
0 - Black
1 - Blue
2 - Green
3 - Cyan
4 - Red
5 - Magenta
6 - Brown
7 - Light Gray
The following colors may be used only for foreground colors:
8 - Dark Gray
9 - Light Blue
10 - Light Green
11 - Light Cyan
12 - Light Red
13 - Light Magenta
14 - Yellow
15 - White
Page 12
EchoDor Version 3.11
3/16/92
Special instructions
PC Board 14
When using this door with PC Board 14 systems, a default security
level of 50 is assigned all users.
PC Board 12
When using this door with PC Board 12 systems, a default security
level of 50 is assigned to all users.
PC Board 12 also requires that the COMPORT parameter be specified.
Opus 1.7x
When using the door with Opus 1.7x systems, the following security
levels will be used:
Twit 32
Disgrace 48
Limited 64
Normal 80
Worthy 96
Privel 112
Favored 128
Extra 144
Clerk 160
Asst-Sysop 176
Sysop 208
GT PowerComm
If you use this Door with GT PowerComm, you must set the MAXTIME
parameter. The GTUSER.BBS file does not contain the amount of time
remaining for the door.
Genesis Deluxe
When using this Door with Genesis Deluxe, you must set the COMPORT
parameter.
LINE-A operation
This option is provided to allow doors to be called without door
information files. All needed parameters are passed on the command
line. The order of the parameters is not important; however, if you
wish to use multiple DoorDriv.Ctl files, you must specify a port
number (without a leading slash or dash) as the first parameter on the
command line. Every other parameter begins with either a slash (/) or
a dash (-) followed immediately by a single letter parameter type.
That type is then followed immediately by the parameter. There should
be no spaces between the dash/slash and the parameter type and there
Page 13
EchoDor Version 3.11
3/16/92
should be no spaces between the parameter type and the parameter. For
example: -b2400 is valid, -b 2400 is not valid.
The following parameters can be specified:
-B baud rate. A baud rate of zero is assumed local.
-P communication port number, COM1 is -P0.
-T time remaining. This is specified in minutes.
-N users name. If specifying a users first & last name, use an
underscore as a separator. For example:
-NFirst_Last
-S numeric security level. For example: -S50 is security level
50.
-M sets the maximum time allowed in door. If the time
remaining is greater than the maximum time, the maximum time
will be used. This is specified in minutes.
-G Specifies graphics/ansi. If the -G is followed by 0,
graphics will be disabled. If the -G is followed by a non
zero value, graphics will be enabled.
If you wish to use a "node number" this must be specified as the first
parameter without a slash or dash.
These parameters should not be used with the /S (sysop log on) or the
/L (local log on) options.
LINE-B operation
This parameter is provided to allow doors to be called without door
information files. All needed parameters are passed on the command
line. Every parameter is order dependent. This style of operation
does not allow user names and provides a default security level of 50.
The following command line is used:
door <port> <baud> <time> <maxtime>
<port> this is the communication port to be used. 1 is assumed
to be COM1. A port of 0 is assumed local.
<baud> this is the baud rate. A baud rate of zero is assumed
local.
<time> this is the time remaining. It's value is in minutes.
<maxtime> this is the maximum time allowed in the door. If the
<time> parameter is greater than the <maxtime>
parameter, the <maxtime> parameter will be used. This
parameter is optional.
Page 14
EchoDor Version 3.11
3/16/92
ECHODOR.CTL parameter file
ECHODOR.CTL is EchoDor's master configuration file. All communication
between you and EchoDor is through this file. Node Number, Net
Number, Sysop name, and many more parameters get their values from
this file. An example file is distributed with EchoDor and is well
commented.
Display file naming
Some of the parameters in the ECHODOR.CTL file specifies files which
can be displayed to the user. Examples of such files are the menu
files (as specified by the MENUFILE, PACKMENUFILE, and DOWNLOADTEXT
parameter) and the welcome files (as specified by the WELCOME
parameter).
EchoDor supports 3 types of displays:
1. Basic text display
2. Graphics display
3. ANSI color display
When EchoDor displays a file and the specified file has an extension
specified, that file will be displayed to the user regardless of the
type of display.
If the file does not have an extension specified then EchoDor will add
an extension to the file depending on display type. The selection
will be:
file.ANS if the user has ANSI color
file.ASC if the user has Graphics
No extension will be added if the user has basic text.
If the user has ANSI color and EchoDor cannot find the specified file
with the extension .ANS, then EchoDor will look for a file with the
extension of .ASC. If that file cannot be found then EchoDor will
look for the file name without an extension.
Page 15
EchoDor Version 3.11
3/16/92
Parameters
All parameters in the EchoDor.Ctl file are specified as an ASCII line
terminated with a carrage return. Most lines (with the exception of
the area tables and the description tables) begin with a key word
followed by a parameter or parameters separated by spaces. The key
word can be upper, lower, or mixed case. If the parameter is not a
literal (like the origin line), the case of the parameter is also
unimportant.
Comments may be included in the control by begining a line with a semi
colon.
The last line of the parameter file should be "--- END ---", or
something like that. There is a quirk in Turbo Pascal that causes the
last line of the file to be skipped.
The following is a list of all the documented parameters that can be
used in the EchoDor.Ctl file.
ADDRESS zone:net/node.point
This parameter should be used in place of the old ZONE, NET, NODE, and
POINT parameters. This is how you specify your default address.
AREATABLE <address>
This parameter begins the area of the control file that defines each
echo area. Each line after this command and prior to the ENDAREATABLE
command consists of 9 space delimited sections. Every section is
required. You may enter the areas in any order you wish, when EchoDor
checks and displays areas, it will be in the same order as you enter
them here. Remember: Do not enter any spaces within the fields, if
you do EchoDor will get confused and will not correctly read the
table.
The AREATABLE command can be followed by an address in the form
zone:net/node.point. This address will be the address used for all
areas in the specified AREATABLE. If you do not specify an address,
you MUST have a ZONE, NET, NODE, and optionally a POINT command or an
ADDRESS command in the file prior to the AREATABLE line.
The sections are:
Page 16
EchoDor Version 3.11
3/16/92
The number.
This is the area number the user would type in to get to
that area. This number must be from 1-255 inclusive (you
can use 1 or 255). You may NOT duplicate this number on ANY
other echo area, local area, or net mail area.
The area tag.
If the area you are defining is an echo, this field must
contain the "defined" name of the echo. You can get this
name from your Echo Mail Coordinator. If it is a local
message area or net mail you may use any name you wish.
DO NOT ENTER ANY SPACES in the area tag!
The listed tag.
This field is shown to the user in the read menu, the scan
menu, and the new messages displays. This field may be
anything you wish; however, you should keep this field to
more than about 30 characters as it may make the display of
certain menus look strange.
DO NOT ENTER ANY SPACES in the listed tag!
The path.
This field tells where the messages for the specific area is
located. Each area must be located in a different
subdirectory. All areas do not have to be on the same
drive.
The type echo.
This field is the "T" column in the ECHODOR.CTL file. This
field tells the kind of message base. The "T" column can
have the following values:
E - the area is a local echo mail message base.
I - the area is national/international echo mail.
N - the area is net mail.
You should normally have one per zone.
B - the area is a local message or auto message area.
A - the area is an auto message area (read only).
The Message Type field.
This field allows you to control a number of different
attributes of the messages being entered in the area.
Page 17
EchoDor Version 3.11
3/16/92
This field allows or prevents private messages in an area.
It also controls what type of user names are placed in the
from field. The field can also turn on GT-Powercomm message
code recognition. This field can contain one ore more
characters depending on what functions are needed.
If this field contains a "Y" or "P", EchoDor will ask if the
message should be marked private. Most echo areas, local
and national, DO NOT allow private messages, so the flag
should be set to "N". The net mail area does allow private
messages so the flag can be set as needed. The local
message areas may also be set as needed.
If this field contains "A", EchoDor will ask if the user
wants to use an ALIAS. If the user has not set up an ALIAS,
EchoDor will tell them that they don't have an alias and it
will tell them how to set it up. If you enable the "A"
option on any echo area, EchoDor will allow the user to
enter an "A" at the user menu to allow setting the alias;
otherwise, EchoDor will not allow the "A" at the user menu.
If you enable both alias and private, EchoDor will allow a
private message sent to a persons alias or real name.
If this field contains a "F", EchoDor will ask if the user
wants to send the message anonymously. Do not mix the Y/N
flag with the F flag. You CAN use the F flag with the A/P
flag.
If this field contains a "G", EchoDor will honor the
GT-Powercomm message control codes. These codes include:
^E - pause
^R - non stop
^T - no abort
If you read an echo that comes from GT-NET you might want to
enable this option.
Examples:
To set an area for ALIAS or anonymous, enter AF or FA in the
field (order is not important). Notice that there is no
spaces between the letters.
To set an area for ALIAS and PRIVATE, enter AP, PA, or AY,
or YA (again order is not important).
To just allow anonymous only, just use F.
File Transfer Flag.
Page 18
EchoDor Version 3.11
3/16/92
File transfer is available in Net Mail areas only. If this
flag is set to "Y", EchoDor will ask if you want to perform
a File [A]ttach / File [R]equest when entering a message in
the net mail area.
This should be used only for net mail areas. Putting file
requests or file attaches into echo areas is undefined.
Security.
This field tells EchoDor the minimum security required to
read messages in the area. The specific security values are
defined by your BBS software. EchoDor reads the security
value passed in the Door information file (DORINFO.DEF,
CALLINFO.DEF, ...etc.) and compares the security passed with
that in this field. The security pass is less, access to
the area will not be allowed.
This field may also contain a 'Y' to indicate that it is a
SYSOP only area. If the user is not listed as a SYSOPNAME
or has the SYSOP flag in the user record, the area will be
restricted from access.
The field can also contain a 'N' to indicate an open area
which is not restricted to anyone.
WRACC (Write access).
This field tells EchoDor the minimum security required to
enter messages in the area. This field works like security
described above.
CHECKDAYS <xx>
This parameter is used to tell EchoDor how often the user must check
his/her mail. This parameter is most useful when you use the "/CHECK"
or the "/AC" options when starting EchoDor.
The day counting may be turned off by specifying a CHECKDAYS 0
parameter.
CLOSINGSTRING bye bye
This parameter will be displayed to the user when he/she exits EchoDor
to return back to the BBS. All the characters following the
"CLOSINGSTRING" key word will be displayed. This parameter is
optional.
COMMANDSTRING <command string>
Normally the main menu displayed by EchoDor is followed by "Main
Command ? ". This is the default value. You can change this prompt
by specifying the COMMANDSTRING parameter.
Page 19
EchoDor Version 3.11
3/16/92
Anything you specify as <command str> up to 80 characters will be
displayed to the user in place of "Main Command ? ". A blank
character is always appended to the end of the command string. Do not
enclose the <command str> in quotes or the quotes will be displayed.
COMMENTAREA <xx>
This is the message area number as defined in the AREATABLE that will
hold all comments to the sysop. This parameter is not required if you
do not enable comments.
When you select an area for comments, be sure this is a local area
(area type B). If you choose a net mail or echo area, your mail
packer will probably send out your comments into the net.
COMMENTNAME Firstname Lastname
Enter the one and only name of the person who will receive comments to
the sysop. This parameter is not required if you do not enable
comments.
COMPRESSDIR <Drive:\Directory>
This command specifies the directory which is used to hold the
compressed mail file after compression. A full directory name can be
used. Drive is optional.
NOTE:
Don't specify any directory used by another program.
The contents of the directory are erased before each compress
operation.
The directory name specified can include a single pound sign (#).
When EchoDor reads the EchoDor.Ctl file it will replace the pound sign
(#) with the node number specified on the command line. This allows
multiple directories to be used for multiple nodes.
COMPRESSFILE <drive:\path\file>
This is the name of the file displayed to users when they select
[C]ompress from the Pack Mail menu. This file should list the
compression programs that are available for compressing mail files.
The file name should not contain an extension. You may create up to
three files to display to the user. See the preceding section on
naming files.
DELETEUSER <xx>
This is the number of days that inactive users will remain in the
EchoDor user file. This parameter is only used by EchoUtil.
Page 20
EchoDor Version 3.11
3/16/92
DESCTABLE
This area begins the description table. This area is required only if
there is not USERAREALIST and SYSOPAREALIST. I suggest that you use
this area only if you do not use the USERAREALIST and SYSOPAREALIST.
If you use this table, it must FOLLOW the AREADESCTABLE. After the
DESCTABLE parameter the table has one line entries until the
ENDDESCTABLE command. Each line must begin with an area number. This
number corresponds with the area number in the AREADESCTABLE, order is
not important. The number must be followed by a single space. The
next 70 characters is the description of the area, you may enter
anything you like, I do suggest that you enter the area name somewhere
in the line. See the EchoDor.Ctl file for an example.
DOWNLOADFILE <Drive:\Path\File>
This is the name of the file displayed to users when they select
[D]ownload from the Pack Mail menu. This file should list the
protocols that are available for downloading mail files. The file
name should not contain an extension. You may create up to three
files to display to the user. See the preceding section on naming
files.
DOWNLOADPROTOCOL <char> <program> <parameters>
The DOWNLOADPROTOCOL parameter is required to tell EchoDor about the
protocols that you wish to make available to users to download packed
mail. There must be at least one DOWNLOADPROTOCOL parameter for mail
downloading to work. There may be as many DOWNLOADPROTOCOL lines as
needed.
The <char> parameter tells EchoDor that character that the user will
type in to activate the protocol. You can use any character except an
asterisk (*). There is no difference in upper case and lower case
characters. You cannot duplicate the same character on multiple
lines.
The <program> parameter tells EchoDor what program to run. The
program must be specified with either the .EXE or the .COM part of the
file name. EchoDor will not directly run batch files; however, you
can always run COMMAND.COM /c batch.bat to perform this operation.
The program does not have to be specified with a path. EchoDor will
search the current 'path' to locate the program; but, if a path is
specified operation will be faster.
The <parameter> part of the command tells EchoDor what to pass to the
program. There are 4 specifications that will be replaced when the
program is called:
%1 = current node number (not usually needed)
%2 = current com port (as a single digit)
%3 = baud rate
%4 = file to download (fill drive and path)
Page 21
EchoDor Version 3.11
3/16/92
Before EchoDor calls the program, it will scan the parameter part of
the command. If it locates a %1, %2, %3, or a %4, it will replace
that with the value as specified above.
Examples of this command are included in "PACKMAIL.CTL".
ENDAREATABLE
This parameter ends the area table descriptions and must be present.
See the AREATABLE command for a description of how to create an area
table.
ENDDESCTABLE
This parameter end the description table section and must be present
if a DESCTABLE is used.
FORUM
Normally EchoDor refers to the message areas as conferences. If your
system uses the term "forum" you may include this word in your
configuration file to have EchoDor refer to your areas as forums.
HELPFILEPREFIX <Drive:\Path\FilePrefix>
This is the prefix for all help files. The file name should not
contain an extension. The path is optional and if omitted, EchoDor
will look for files in the current directory.
HOTKEYS
When this parameter is included in the EchoDor#.Ctl file, EchoDor will
use hot keys for all menu operations. The user will not have to press
the enter key. This is included for sysops wish to have EchoDor more
closely emulate the operation of their BBS.
INCLUDE <Drive:\Path\FileSpec>
The INCLUDE parameter allows the sysop to tell EchoDor to read an
additional file during startup. This parameter is most useful for
sysops that use multiple EchoDor#.Ctl files. The parameters that are
the same for each node can be placed in the "included" file. When
EchoDor starts it will read the EchoDor#.Ctl file as normal. When it
encounters the INCLUDE parameter, the specified file will be read.
EchoDor will then complete reading the EchoDor#.Ctl file.
LOGFILE <Drive:\Path\File>
This is the name of the file that EchoDor is to use for logging
activity. If the LOGFILE parameter is not specified, EchoDor will not
do logging.
Page 22
EchoDor Version 3.11
3/16/92
The file name specified can include a single pound sign (#). When
EchoDor reads the EchoDor.Ctl file it will replace the pound sign (#)
with the node number specified on the command line. This allows
multiple log files to be used for multiple nodes.
LOGTYPE <chars>
This specifies the type of logging information to be recorded. The
<chars> parameter contains the letter category(s) to be logged. The
following categories are available:
: (colon) - general information
+ (plus) - read/scan information
$ (dollar) - write/change/kill information
Multiple categories can be specified:
LOGTYPE +$
If logging is enabled and the LOGTYPE parameter is not specified, full
logging will occur.
MAILFILE <Drive:\Path\FileSpec>
This is the file name (and path) where you wish mail packed for
download to be placed. It should be in a directory that the files
section of your BBS can access or somewhere where the download
functions can find the file. This parameter is not required if you do
not enable packed mail. The drive and path are optional and if
omitted, EchoDor will create the mail file in the current directory.
EchoDor will automatically create and delete this file depending on
the user.
The file name specified can include a single pound sign (#). When
EchoDor reads the EchoDor.Ctl file it will replace the pound sign (#)
with the node number specified on the command line. This allows
multiple mail files to be used for multiple nodes.
MAXLINELENGTH <xx>
This parameter allows you to tell EchoDor to shorten lines. Normally
EchoDor sets the default line length to 75 characters. This parameter
allows you to adjust this maximum from 40 to 75 characters in length.
If a value is specified that is outside that range, 75 will be used.
This parameter also effects the length of lines that can be entered on
the full screen editor.
MAXUSERTIME <xx>
This is the maximum session time in minutes.
MENU opt seclvl <Drive:\Path\FileSpec>
Page 23
EchoDor Version 3.11
3/16/92
This is an enhancement to the USERAREA and SYSOPAREA files which can
be displayed to a user. Normally a user will select an area by
specifying either the name or number of the desired area. Some BBS
system carry a large number of conferences .. too many to place on a
single screen.
The "opt" is a single letter. Any letter except Q & L can be used.
When that letter is selected the file specified on the MENU statement
will be displayed to the user the security level of the user is equal
to or greater than the specified "seclvl".
The "seclvl" is the security level the user must have to access the
area. The user level must be equal to or greater than the level
specified.
The "FileSpec" specified should not contain an extension. Up to three
files may be created. See the preceding section on file names.
Using the MENU command, the areas displayed to the user may be divided
into sections. The individual sections are selected by a single
letter - the "opt". When the letter is selected the file specified
will be displayed to the user.
A specific area may be selected from ANY menu by specifying the name
or number of the area. Also, access to every menu is available from
any other menu.
MENUFILE <Drive:\Path\File>
This is the name of the main menu file. It should not contain an
extension. You should create 3 files for the menu. See the preceding
section on naming files. The drive and path are optional and if
omitted, EchoDor will look for the menu files in the current
directory.
MONO
Use this option if you are using a monochrome system but still want
your users to see color ANSI screens on their side.
MSGTEXTCOLOR <xx>
This is the color set when displaying or entering message text. See
the list of colors below.
NET <xx>
This parameter specifies either a Fidonet NET number or a RBBSNET net
number.
This parameter MUST be specified before the first AREATABLE parameter.
Don't use this parameter if your using the ADDRESS parameter.
NEWQUOTE
Page 24
EchoDor Version 3.11
3/16/92
Starting with EchoDor v3.10 we have two methods of doing quotes in
full screen mode. The original method is available by default. A
faster method of doing quotes which will automatically insert the
quote without the second operation is available. To switch to this
new method of quoting, insert the NEWQUOTE parameter in the
EchoDor.Ctl file.
NOCOMMENT
This option will disable the comment feature.
NODE <xx>
This is your Fidonet or Rbbsnet node number. It usually is between 1
and 4 digits in length, and SHOULD NOT include a point address IE:
(100.0) leave off the point information.
EchoDor requires that the node number specified be non-zero.
This parameter MUST be specified before the first AREATABLE parameter.
Don't use this parameter if your using the ADDRESS parameter.
NODELISTPATH Type <Drive:\Path\>
This tells EchoDor the subdirectory that contains the nodelist files
and the type of nodelist file to use.
Starting with EchoDor v3.10a, two types of nodelists can be used. The
first is a compiled version 6 nodelist files (NODELIST.DAT &
NODELIST.NDX). When using this set the "Type" field in the
NODELISTPATH line to V6. The second type of nodelist available is a
special nodelist which is a combination of index files and the raw
nodelist file. The index files are created by the EchoDor nodelist
compiler. When using this type of nodelist specify ED as the "Type"
field.
Also, starting with EchoDor v3.10a this parameter is optional even if
net mail is used; however, omitting this parameter will remove
net/node number checking and verification as well as the ORIG/DEST
lines while reading net mail.
NOIGNORE
This will disable the ignore command. The ignore command is used to
exclude certain areas from the message check. This is useful if you
have a lot of echoes, and checking them all would take a very long
time.
NOPACKMAIL
This disables the pack mail feature. If you do not include this
command then the "MAILFILE" command is required.
Page 25
EchoDor Version 3.11
3/16/92
NOSETNATIONAL
By default, EchoDor will set everyones ignore status to ignore
national echoes. This option will set All echoes to be checked.
NOTAVAIL <Drive:\Path\FileSpec>
If specified, this file will be displayed to users that try to access
an area which they don't have access to because of security. If this
parameter is not specified, the system will issue an access not
allowed type message. The drive and path are optional. If not
specified EchoDor will look in the current directory for the file.
NOWRITE <Drive:\Path\File>
If specified, this file will be displayed to users that try to enter a
message into an area for which they do not have write access. If this
parameter is not specified, the system will issue an access not
allowed type message. The drive and path are optional. If not
specified EchoDor will look in the current directory for the file.
NUMHELPFILES <xx>
This is the number of help files (Not including the menu!).
ORIGIN your origin line from your Areas.BBS file
This is the origin line that will be appended to all messages entered
with EchoDor. It should look the same as the one in your AREAS.BBS
file (part of the echo mail system). Do not include your net/node
number in your origin line. Versions of EchoDor later than 3.00 will
append your net node number to the end of your origin line.
If you want an area to have different origin line from the one
specified in the ORIGIN parameter, create a file called ORIGIN in that
message area. Put one line in this file, do not include your net/node
number on the line. When EchoDor saves your message it will check for
this file. If it finds one it will use the first line of the file to
replace the ORIGIN line specified here. You do not have to have an
ORIGIN file in every area, if the ORIGIN file does not exist in some
areas, EchoDor will use the ORIGIN line specified in this parameter.
OUTBOUND <Drive:\Path>
This is the full drive and path of your outbound directory. The drive
and path are required. This parameter is only used by EchoUtil for
tasks such as REQFILE, SENDFILE, ATTLIST.
PACKERPROGRAM <char> <program> <parameters>
The PACKERPROGRAM parameter is required to tell EchoDor about the
archiving programs that you wish to make available to the users to
compress mail. There must be at least one PACKERPROGRAM parameter for
the [C]ompress option to work. There may be as many PACKERPROGRAM
lines as needed.
Page 26
EchoDor Version 3.11
3/16/92
The <char> parameter tells EchoDor what character that the user will
type in to activate the archive program. You can use any character
except asterisk (*). There is no difference between upper case and
lower case characters. You cannot duplicate the same character on
multiple lines.
The <program> parameter tells EchoDor what program to run. The
program must be specified with either the .EXE or the .COM included as
part of the program name. EchoDor cannot run batch files; however,
you can always run:
COMMAND.COM /c batch.bat
to perform this operation. The program does not have to be specified
with a path. EchoDor will search the current 'path' to locate the
program; but, if the path is specified operation will be faster.
The <parameter> part of the command tells EchoDor what to pass to the
program. There are 2 specifications that will be replaced when the
program is called:
%1 = name of the file to compress. (includes drive and path).
%2 = directory where to place the compressed file.
Before EchoDor calls the specified program, it will scan the parameter
part of the command. If it locates a %1 or %2, it will replace that
with the value as specified above.
PACKMENUFILE <drive:\path\file>
This is the name of the pack menu file. This file is displayed to the
user when the [P] command on the main menu is selected. It should not
contain an extension. You should create 3 files for the menu. See the
preceding section on naming files. The drive and path are optional
and if omitted, EchoDor will look for the menu files in the current
directory.
You should include the following options on the menu:
[A] - Area Change or [J] - Join area
[B] - Set read criteria
[I] - Personal Mail Setup
[K] - Kill pack mail file
[P] - Pack Mail for download
[C] - Compress Packed Mail
[D] - Download Packed Mail
[Q] - Quit to main menu
PACKMAILTEXT <drive:\path\file>
Page 27
EchoDor Version 3.11
3/16/92
The file on this line will be displayed to any user that has caused a
pack mail to be generated. This is usually used to tell the user where
to find the mail file, for example:
Your mail is packed ... you may download using [D].
POINT <xx>
This parameter specifies the POINT part of your net node number.
EchoDor does not currently provide point remapping; however, this
value is placed in the ORIGIN line to complete the net node number.
This parameter if used MUST be specified before the first AREATABLE
command.
Don't use this parameter if your using the ADDRESS parameter.
READHELPFILE <drive:\path\file>
This specifies the name of the help file which is displayed to the
user when a question mark (?) is entered at the read menu.
SCANBARCOLOR <xx>
This is the color set on the top line of the scan message display.
SCANLINECOLOR <xx>
This is the color set for each line displayed after the scan bar line
during the Scan Messages function.
SCANLOGNAME <Drive:\Path\FileSpec>
This tells EchoDor the full path name where the scan log file should
be written. This file is used by programs such as QM or ConfMail to
specify the echo mail areas which contain new messages. This file
will only be written when a user enters a message into an echo mail or
net mail area. The drive and path are optional and if omitted,
EchoDor will create the scan log file in the current directory.
Note:
After mail is scanned by a mail scanner program (such as QM or
ConfMail) this file MUST BE DELETED. Because a user may go in
and out of EchoDor numerous times during a session, EchoDor will
not delete this file but will read it in and append new areas to
it.
The file name specified can include a single pound sign (#). When
EchoDor reads the EchoDor.Ctl file it will replace the pound sign (#)
with the node number specified on the command line. This allows
multiple scan log files to be used for multiple nodes.
SYSOPAREALIST <Drive:\Path\FileSpec>
Page 28
EchoDor Version 3.11
3/16/92
This is the file displayed to the SYSOP when the L)ist areas function
is selected. See the above description on naming files. This
parameter is required if you do not use the AREADESC. The drive and
path are optional.
UPLOADDIR <Drive:\Directory>
This command specifies the directory which will hold the uploaded file
after completing a mail upload. A full directory name can be used.
Drive is optional.
Note:
Don't specify any directory used by any other program. The
contents of this directory is erased before each upload
operation.
The directory name specified can include a single pound sign (#).
When EchoDor reads the EchoDor.Ctl file it will replace the pound sign
(#) with the node number specified on the command line. This allows
multiple directories to be used for multiple nodes.
UPLOADFILE <Drive:\Path\File>
This is the name of the file displayed to users when they answer Y to
the "Do you want to up load a message" question. This file should
list the up load protocols that are available. The file name should
not contain any extension. You may create up to three files to
display to the user. See the preceding section on naming files.
UPLOADPROTOCOL <char> <program> <parameter>
The UPLOADPROTOCOL parameter is required to tell EchoDor about the
protocols that you wish to make available to users to up load
messages. There must be at least one UPLOADPROTOCOL parameter for
message up loading to work. There may be as many UPLOADPROTOCOL lines
as needed.
The <char> parameter tells EchoDor that character that the user will
type in to activate the protocol. You can use any character except an
asterisk (*). There is no difference in upper case and lower case
characters. You cannot duplicate the same character on multiple
lines.
The <program> parameter tells EchoDor what program to run. The
program must be specified with either the .EXE or the .COM part of the
file name. EchoDor will not directly run batch files; however, you
can always run COMMAND.COM /c batch.bat to perform this operation.
The program does not have to be specified with a path. EchoDor will
search the current 'path' to locate the program; but, if a path is
specified operation will be faster.
The <parameter> part of the command tells EchoDor what to pass to the
program. There are 4 specifications that will be replaced when the
program is called:
Page 29
EchoDor Version 3.11
3/16/92
%1 = current node number (not usually needed)
%2 = current com port (as a single digit)
%3 = baud rate
%4 = up load directory (as specified in EchoDor.Ctl)
Before EchoDor calls the program, it will scan the parameter part of
the command. If it locates a %1, %2, %3, or a %4, it will replace
that with the value as specified above.
Before the up load is started, EchoDor will switch to the up load
directory and make the specified drive the default drive. This will
allow you to use DSZ and not have to worry about specifying the place
to put the file. After the up load completes, EchoDor will switch
back to it's start up directory and drive.
You don't have to worry about the name of the file that is uploaded.
EchoDor will import every file that it finds in the up load directory.
USERAREALIST <Drive:\Path\File>
This is the file displayed to the user when the L)ist areas function
is selected. See the above description on naming files. This
parameter is required if you do not use the AREADESC. The drive and
path are optional.
USERFILE <Drive:\Path\FileSpec>
This is the name of the user file maintained by EchoDor. If this
parameter is not specified the default will be EchoUser.BBS in the
current directory.
Note:
This parameter is required when running a multi-node system. All
copies of EchoDor must share the same USERFILE.
VISUALESC <char>
This option tells EchoDor to allow these characters to represent the
<ESC> character when entered on the first character of a line when in
the visual editor. A lot of people are used to entering .S or /S as
the first characters of a line when they want to save the message. If
you set this parameter something like:
VISUALESC ./\
Then if the user enters any of the three characters (period, back
slash, or slash) as the first character of a line, Visual Editor will
react as if the user pressed the <ESC> key. So if the user types .S
the message will be saved. This is a nice feature to have an users
will appreciate it.
WELCOME <Drive:\Path\FileSpec>
Page 30
EchoDor Version 3.11
3/16/92
This is the name of the welcome file that is to be displayed each time
a user accesses the echo mail door. See the above description on
naming files. The drive and path are optional.
If you do not wish to have a welcome file displayed to the user then
remove this command.
ZONE <xx>
This parameter specifies you ZONE part of your net node number. For
Fidonet boards running in the US, this will be 1, for Rbbsnet boards
running in the US, this will be 8.
This parameter MUST be specified before the AREATABLE command in the
control file.
Don't use this parameter if your using the ADDRESS parameter.
Page 31
EchoDor Version 3.11
3/16/92
Color Table
The follow colors may be used for both background colors and foreground
colors:
0 - Black
1 - Blue
2 - Green
3 - Cyan
4 - Red
5 - Magenta
6 - Brown
7 - Light Gray
The following colors may be used only for foreground colors:
8 - Dark Gray
9 - Light Blue
10 - Light Green
11 - Light Cyan
12 - Light Red
13 - Light Magenta
14 - Yellow
15 - White
Some parameters allow you to specify both a foreground and a background
color; however, you must specify it in a single number (the parameter
PROMPTCOLOR is an example of this). To figure the number you want:
First pick out your background color and multiply that number by 16. Then
add your foreground color. For a background of red and a foreground of
white.
Red = 4.
4 x 16 = 64.
White = 15.
64 + 15 = 79.
Therefore the number you specify is 79.
Page 32
EchoDor Version 3.11
3/16/92
SYSOP setup
Every system has a SYSOP. This is the person that is responsible for the
operation of the BBS. Other people may also be required to assist in the
SYSOP functions, so a BBS may have multiple people that have SYSOP or
assistant SYSOP access.
The EchoDor system supports as many Sysops as needed. When first setting
up EchoDor you must tell EchoDor that you are the SYSOP. First you must
log into EchoDor, if you are just setting up EchoDor you should have
already logged into the system once to check it. If you have not already
done so, start EchoDor. This will put your name into the EchoDor users
file.
EchoDor /s
The '/s' tells EchoDor that you are performing a "fast logon as sysop".
Now exit EchoDor.
You now need to start EchoUser. Do this as:
EchoUser /s
Now select yourself as the record to update. Use the [U] function and
enter your name as you typed it in the DoorDriv.Ctl file. You should be
presented with a list of users (possibly only 1). Enter the number
displayed to the left of the name. EchoUser will then display you as the
user. This is the record that will be effected by the changes you are
about to make.
Now select [S]ysop flag. The program will tell you that the flag is either
off or on and will ask if you want to change it. If it says OFF, answer Y
when it asks if you want to turn the flag on. It will then tell you that
the user is now a SYSOP. If you need the menu back, just press enter.
With some systems (Wildcat! being one of them) it may be necessary to set
the SYSOP security level. When you log on the system locally (using /L or
/S), EchoDor sets the security level to 1024. This may not be high enough
for some systems. If you need to have a higher security level select
[L]evel from the menu. EchoUser will probably tell you that the user uses
the level from the BBS (you'll want this for most users). For yourself,
set the security level that you need as SYSOP. When you set a security
level in this way, that will be the security level that you will receive
every time you enter EchoDor, either locally or through the BBS.
You can repeat this for every user that you want to setup as a sysop.
Page 33
EchoDor Version 3.11
3/16/92
Pack Mail / Compress / Download Setup
A user may now pack mail, compress and then download this mail packet with
EchoDor. To fully implement these features you must make modifications in
the ECHODOR.CTL file. Older versions of EchoDor also required
modifications of the EchoDor batch file, this need has been eliminated.
All compression is performed by external archiving programs. The mail file
name containing the text is passed as one of the parameters to the
compression program. A second parameter specifies the directory where the
compressed file should be placed. The specific name of the compressed file
is not important as EchoDor will transfer any file it finds in that
directory to the user (you can even put advertisements into the directory).
All downloads are implemented with external protocols. One of the most
popular is DSZ. The included batch files give examples using DSZ for X, Y,
and Z modem. Note that DSZ is a shareware program. Registering EchoDor
does not give you the right to use DSZ. You should register that program
also.
Basic Setup
To implement Pack Mail you must include the following commands in the
EchoDor.Ctl file:
PACKMENU
This command tells EchoDor where to find the PACKMENU files to be
displayed to the user when he/she selects [P]ack Mail from the
main menu.
You should include the following options on the menu:
[A] - Area Change or [J] - Join area
[B] - Set read criteria
[I] - Personal Mail Setup
[K] - Kill pack mail file
[P] - Pack Mail for download
[C] - Compress Packed Mail
[D] - Download Packed Mail
[Q] - Quit to main menu
PACKMAILTEXT
This command tells EchoDor the name of the file to display to the
user when he/she has complete packing mail. This file might say
something like:
Your mail is packed. You may download using [D].
MAILFILE
Page 34
EchoDor Version 3.11
3/16/92
This command tells EchoDor the name to use for the file created
that contains the packed mail. This file name can include a full
drive, path, and file specification.
Don't put this file into the compress or download directory.
Note:
If you run multiple nodes, this file must be different for
each node.
This difference may come by being in different default
directories or by using a different name in the different
EchoDor#.Ctl files.
You can also make the files different by including a pound
symbol (#) in the file name. When EchoDor starts, it will
replace the pound symbol (#) with the current node number.
If you only run a single node, this file may be anything you
want.
You must also make sure that the NOPACKMAIL command in the EchoDor.Ctl file
is commented out or removed.
Compressing Mail
To implement the mail compress feature of EchoDor, you must include the
following additional parameters in the EchoDor.Ctl file.
COMPRESSFILE <filename>
This contains the name of the file to display to the user when
[C]ompress is selected from the pack mail menu file. The file
should contain a list of the available archive programs that can
be used to compress the mail file.
COMPRESSDIR <Drive:\Path>
This command specifies the directory which will be used by the
compress program to hold the compressed mail file. This file is
checked by EchoDor during download to figure out of the user
wants to download compressed mail or uncompressed mail.
NOTE:
DO NOT USE THIS DIRECTORY FOR ANYTHING ELSE !!!!
This directory is completely erased by EchoDor each time a new
user logs into the system.
PACKERPROGRAM <char> <program> <parameters>
Page 35
EchoDor Version 3.11
3/16/92
The PACKERPROGRAM parameter is required to tell EchoDor about the
archiving programs that you wish to make available to the users
to compress mail. There must be at least one PACKERPROGRAM
parameter for the [C]ompress option to work. There may be as
many PACKERPROGRAM lines as needed.
The <char> parameter tells EchoDor what character that the user
will type in to activate the archive program. You can use any
character except asterisk (*). There is no difference between
upper case and lower case characters. You cannot duplicate the
same character on multiple lines.
The <program> parameter tells EchoDor what program to run. The
program must be specified with either the .EXE or the .COM
included as part of the program name. EchoDor cannot run batch
files; however, you can always run:
COMMAND.COM /c batch.bat
to perform this operation. The program does not have to be
specified with a path. EchoDor will search the current 'path' to
locate the program; but, if the path is specified operation will
be faster.
The <parameter> part of the command tells EchoDor what to pass to
the program. There are 2 specifications that will be replaced
when the program is called:
%1 = name of the file to compress. (includes drive and
path).
%2 = directory where to place the compressed file.
Before EchoDor calls the specified program, it will scan the
parameter part of the command. If it locates a %1 or %2, it will
replace that with the value as specified above.
Downloading Mail
To implement the downloading feature of EchoDor, you must include the
following additional parameters in the EchoDor.Ctl file:
DOWNLOADFILE <filename>
This contains the name of the file to display to the user when
[D]ownload is selected from the pack mail menu file. The file
should contain a list of the available protocols that can be used
to download.
DOWNLOADPROTOCOL <char> <program> <parameters>
Page 36
EchoDor Version 3.11
3/16/92
The DOWNLOADPROTOCOL parameter is required to tell EchoDor about
the protocols that you wish to make available to users to
download packed mail. There must be at least one
DOWNLOADPROTOCOL parameter for mail downloading to work. There
may be as many DOWNLOADPROTOCOL lines as needed.
The <char> parameter tells EchoDor that character that the user
will type in to activate the protocol. You can use any character
except an asterisk (*). There is no difference in upper case and
lower case characters. You cannot duplicate the same character
on multiple lines.
The <program> parameter tells EchoDor what program to run. The
program must be specified with either the .EXE or the .COM part
of the file name. EchoDor will not directly run batch files;
however, you can always run COMMAND.COM /c batch.bat to perform
this operation. The program does not have to be specified with a
path. EchoDor will search the current 'path' to locate the
program; but, if a path is specified operation will be faster.
The <parameter> part of the command tells EchoDor what to pass to
the program. There are 4 specifications that will be replaced
when the program is called:
%1 = current node number (not usually needed)
%2 = current com port (as a single digit)
%3 = baud rate
%4 = file to download (full drive and path)
Before EchoDor calls the program, it will scan the parameter part
of the command. If it locates a %1, %2, %3, or a %4, it will
replace that with the value as specified above.
Don't worry about trying to decide if to download a compress file
or a plain text file, EchoDor will make the selection and pass
the correct file name.
Examples of this command are included in "PACKMAIL.CTL".
Page 37
EchoDor Version 3.11
3/16/92
Multiple Node Setup
Another name for a multiple node setup is a multiple line setup.
EchoDor has always supported multiple nodes. However, with the
additional options that are available and the somewhat varied systems
supported, I thought a separate section explaining methods to be used
to setup a multiple node system would be in order.
There are two basic ways to set up EchoDor for multiple node
operation. The first way is the "common directory" method. Using
this method, all the EchoDor files are in a single directory and node
numbers are used to differentiate between users on the different
nodes. The second way is to use a separate directory for each node
you plan to run. This operation uses the "default" directory to keep
multiple users separate. Depending on the way you run your board and
the BBS software you use will make one of the two methods most
effective for your operation. The following sections explain how to
set up each of the two methods and suggestions for when to use it.
Page 38
EchoDor Version 3.11
3/16/92
The Common Directory Method
The common directory method places all the EchoDor files into a single
directory. EchoDor is then started with a different node number for each
node. This method is most effective when using BBS systems that run
multiple nodes using node numbers and creates door information files with
different names for each node (such as RBBS).
How to set up the "common directory" system:
1. Create a directory to hold all the EchoDor files. This is the same
way you would set up EchoDor for a single node system. We will call
this the EchoDor Main Directory. EchoDor will never change
directories during it's operation.
You must make sure that the ECHODNLD & ECHOCMPS batch files don't
change directories either, watch out for download protocol programs
and compress programs that change the directory without you telling
them.
2. If you intend to use the COMPRESS feature in EchoDor set up a separate
subdirectory within the EchoDor Main Directory for each node. Use
names something like this:
COMPRES0 - local use
COMPRES1 - Node 1 use
COMPRES2 - Node 2 use
.
.
COMPRES9 - Node 9 use
3. Make the following changes to your EchoDor.Ctl file:
a. If you use the SCANLOGNAME command, change it to something like:
SCANLOGNAME EchoDor\Scan#.Log
Notice the '#' in the name. This will be replaced with the node
number you use to start EchoDor.
b. If you are using the mail file features of EchoDor (which is
always used with COMPRESS & DOWNLOAD) you must change the
MAILFILE command to something like this:
MAILFILE Mail#.Txt
Notice the '#' in the name. This will be replaced with the node
number you use to start EchoDor.
c. If you are using the mail compress feature of EchoDor you will
need to change the COMPRESSDIR command to something like:
COMPRESSDIR COMPRES#
Page 39
EchoDor Version 3.11
3/16/92
Notice the '#' in the directory name. This is replaced with the
node number you use to start EchoDor. The "COMPRES#" name will
be changed to names like "COMPRES0", "COMPRES1", and so on. The
names must match the directories you created in the above
section.
4. Also, you will have to make your batch files that control scanning the
mail after it is entered aware of the log names. In place of making a
very complex batch file to decide which log to pass to your mail
packer, you can use SCANMRG to combine the various scan logs into a
single log, then perform a single scan once a day. To perform this
operation you would add a command such as:
SCANMRG EchoDor\Scan%1.Log EchoDor\ScanLog.Log
This command goes in your EchoDor.Bat file after the IF ERRORLEVEL 3
line. This would combine all the Scanlogs for the various nodes into
a single ScanLog. An explanation of SCANMRG is in sections that
follow. You should not replace the SCANMRG with a copy/append command
as the operation of SCANMRG is different.
5. If the various nodes in your system need other changes in the
EchoDor.Ctl file for reasons such as different echos, different
privileges or other such reasons, EchoDor allows you to create a
separate EchoDor.Ctl file for each node. The specific file used is
created by changing the name of the base file:
EchoDor.Ctl - this is the default file
EchoDor0.Ctl - this would be used for local operation
EchoDor1.Ctl - this would be used for node 1
EchoDor2.Ctl - this would be used for node 2
.
.
EchoDor9.Ctl - this would be used for node 9
You should still make the changes outlined above in the EchoDor.Ctl
file before you make copies of it for the various nodes. This will
help prevent errors when you create the EchoDor#.Ctl files for the
various nodes.
Also, be sure the EchoDor.Ctl file contains EVERY message are you
intend to carry. This is the file used by EchoUtil when performing
maintenance.
Finally, be aware that should a node look for it's EchoDo#.Ctl file
and one is not present, EchoDor will use the default (EchoDor.Ctl)
file.
6. If the various nodes in your system require different information in
the DoorDriv.Ctl file, such as for different types of modems or
different BBS names or different SYSOP names, EchoDor allows multiple
DoorDriv.Ctl files to be used for each node. The specific file used
is created by changing the name of the base file:
DoorDriv.Ctl - this is the default file
Page 40
EchoDor Version 3.11
3/16/92
DoorDri0.Ctl - this is used for local operation
DoorDri1.Ctl - this is used for node 1
DoorDri2.Ctl - this is used for node 2
.
.
DoorDri9.Ctl - this is used for node 9
If EchoDor looks for it's DoorDri#.Ctl file and cannot find it, it
will use the default (DoorDriv.Ctl) file.
Page 41
EchoDor Version 3.11
3/16/92
Multiple Directory Method
The multiple directory method sets up a single directory to hold all the
"common" EchoDor files and separate directories for the "node specific"
files. This method is most effective when used with BBS systems that do
not provide "node number" information and always names the door information
file the same (such as WildCat!).
To set up a "multiple directory" system do the following:
1. Create a "common" directory which will be shared between all the nodes
in the system. Put the following files in this directory (check your
EchoDor.Ctl file for the exact names):
EchoUser.BBS - this is the main user file
The MENUFILE files (used for the main menu)
The PACKMENUFILE files (used for the pack menu)
The USERAREALIST files (conference lists)
The SYSOPAREALIST files (sysop conference list)
The MENU files (conference menu files)
The help files
The DOWNLOADFILE
The COMPRESSFILE
The NOTAVAIL file
The NOWRITE file
The PACKMAILTEXT file
The WELCOME files
Also, put a copy of the DoorDriv.Ctl & EchoDor.Ctl file into this
directory. We will use the files in the "common" directory to make a
model for all the other directories.
2. Now we will edit the EchoDor.Ctl file that we have placed in the
common directory. The following lines should be changed to include a
full drive, path, and file name so that the various nodes can find
these files:
USERFILE <drive:\path\file>
This is probably the most important line in the EchoDor.Ctl file when
using multiple node / multiple directory setups. This tells EchoDor
where to find the main user file. Be sure to specify a full drive,
path, and file name in this line. This will cause EchoDor to share
the file between nodes.
MENUFILE
PACKMENUFILE
USERAREALIST
SYSOPAREALIST
NOWRITE
NOTAVAIL
HELPFILEPREFIX
MENU
DOWNLOADFILE
COMPRESSFILE
Page 42
EchoDor Version 3.11
3/16/92
PACKMAILTEXT
WELCOME
Now we are going to edit the lines which are "node" dependent. These
lines will NOT include a full path but will only include file names or
directory names. DO NOT use the '#' in the file name. This should
only be used for "common directory" operation.
MAILFILE <filename>
Only use a file name. Don't include a drive or path. For example:
MAILFILE mailfile.txt
COMPRESSDIR <directory name>
Only use a single name. Don't include a drive or path. For example:
COMPRESSDIR compress
SCANLOGNAME <filename>
Only use a file name. Don't include a drive or path. For example:
SCANLOGNAME scanlog.log
Be sure this "default" EchoDor.Ctl file contains ALL the message areas
that you intend to carry on your system. We will use this file during
maintenance (EchoUtil /M) to tell EchoUtil where ALL the areas are to
be processed.
Save the EchoDor.Ctl file.
3. Now we need to edit the DoorDriv.Ctl file. Make all the changes
outlined in the above section. Then:
Remove the BBSPATH line. It will be necessary to "pick up" the door
information file from the default / current directory.
We may have to make other changes in the DoorDriv.Ctl file based on
the "node" but we'll save that for a little later. Save the
DoorDriv.Ctl file.
4. Create a separate subdirectory for each node that you intend to run.
5. Switch to the subdirectory that you created for one of the nodes.
Remember which node this directory is going to be used for. Then do
the following:
Copy the EchoDor.Ctl file in the "common" directory to this directory.
Do not rename the file. It should still be EchoDor.Ctl.
Copy the DoorDriv.Ctl file in the "common" directory to this
directory. Do not rename the file. It should still be EchoDor.Ctl.
Page 43
EchoDor Version 3.11
3/16/92
Copy the EchoDor.BAT file into the current directory.
If you are using the COMPRESSDIR command in your EchoDor.Ctl file,
create a directory with the name you specified in the COMPRESSDIR
command. The COMPRESSDIR command in your EchoDor.Ctl file should only
contain the name of the directory. It should not include any drive or
path specifications.
6. Depending on your BBS and system requirements, you may have to edit
the DoorDriv.Ctl file. Based on the node you may have to change:
The BAUD line. If this node runs a locked baud be sure to include a
BAUD line.
The COMPORT line. If your BBS does not provide the com port in the
door information file, edit this line to tell EchoDor which port to
use for this node.
Make any other changes that are needed for this specific node. Then
save the DoorDriv.Ctl file.
7. Edit the EchoDor.BAT file:
Include a line to copy the door information file from THIS NODE's BBS
directory to the current directory.
Perform the needed operations to get the SCANLOGFILE into where ever
it needs to go. This will depend a great deal on how you process the
newly entered messages.
Do what ever is needed to get you back to your bbs directory to
restart / reload your BBS program.
8. If you use COMPRESS and/or DOWNLOAD, be sure the ECHOCMPS and the
ECHODNLD batch files are placed somewhere on your PATH. This is so
the main EchoDor.BAT file can find them. If you don't want to place
these batch files in your path, place a copy of them in each node's
subdirectory.
The following special considerations must be made when performing the mail
compress and renumber.
1. Be sure that the EchoDor.Ctl file contained in the "common" directory
contains EVERY message area that you are carrying on line.
2. When performing purge and renumber, be sure to switch to this
directory before you run EchoUtil /M.
Page 44
EchoDor Version 3.11
3/16/92
Multiple Net Setup
Starting with version 3.03 of EchoDor, multiple net/node numbers may be
used. The system will only allow one net/node number per echo area;
however, your echo areas may be split up into groups with a different
net/node number for each group.
When an echo message in entered, the specified net/node number which
applies to that area is appended to the origin line and placed in the
origin fields in the message. Normally only one net/node number is
specified in the EchoDor.Ctl file; however, if you follow the structure of
the example below you can have EchoDor place the correct net/node number,
in a multi-net setup, in the origin line and message depending on the echo
area where the message was entered.
To use multiple net/node numbers you must group your echo areas together
using AREATABLE / ENDAREATABLE specifications and multiple ZONE, NET, NODE,
and POINT commands. Using the following as an example of what might be in
a EchoDor.Ctl file:
Specify your default ADDRESS 1:116/1000.0
Now specify the areas which should use 1:116/1000.0 in their origin line.
The AREATABLE / ENDAREATABLE should be exactly like what would be used for
a single net. Notice that the AREATABLE line does not have an address
specified. This will cause the AREATABLE to use the address specified on
the ADDRESS line above. You could also specify 1:116/1000.0 on the
AREATABLE line but it will produce the exact same effect. See the above
description for how to specify an AREATABLE.
AREATABLE
1 echoone echotag path ...........etc.
2 echotwo echotag path ...........etc.
ENDAREATABLE
Now come the areas which should use 8:255/120.0 in their origin line.
Notice that an address is specified on the AREATABLE line. This will
override the default address specified on the ADDRESS line.
AREATABLE 8:255/120.0
3 echothree echotag .......
4 echofour echotag .......
ENDAREATABLE
Notice that the AREA NUMBERS in the first AREATABLE and the second
AREATABLE were NOT duplicated. An area number may only appear once even
when you use multiple AREATABLEs.
Also, if you use the AREADESC to specify the descriptions for your areas,
all the areas in both nets may be specified in a single AREADESC /
ENDAREADESC.
EchoDor is not limited to only two nets. You may specify as many
zone:net/node groups as you require for your setup. The total number of
Page 45
EchoDor Version 3.11
3/16/92
areas (echo, local, and net mail) for all areas added together may not
exceed 255.
Page 46
EchoDor Version 3.11
3/16/92
Purging & Renumbering Areas
There are now two different methods of purging and renumbering your message
areas. One was is to use the three step process of purge, EchoUtil /m,
renumber. This method offers some advantages of allowing you to use any
purge/renumber program you want. The disadvantage of this method is the
time involved. The second way to purge and renumber areas is to use
EDorPurg. This program can purge, renumber, and update the user file in a
single operation. Both methods are described here.
The Three Step Method
Purging and renumbering your message areas is a three step process.
You must not omit any of these steps otherwise the last read pointers
will not be correctly set. These steps include:
Old messages are deleted. At this time the messages should NOT be
renumbered. This is purging.
Second, EchoUtil must be run in maintenance mode (EchoUtil /M) to
figure out what each users last read pointer should be after the
message bases are renumbered (next step). Note: This step must be
performed BEFORE the actual renumbering the message areas.
Third, the message areas are renumbered.
There are a number of utilities which can perform the first (purge)
and third (renumber) steps. Starting with EchoDor 3.05, I am
providing automated assistance in generating the required files to
perform these operations using RASMSM v2.00 or later.
RASMAM is a program written by Roger Smith, Jr of 1:366/14. The
program is geared for Opus but works great for any other system which
uses the #.msg format for messages. Please remember that this program
is also a shareware program. Registration of EchoDor does not entitle
you to use RASMAM without registration.
I currently have a copy of RASMAM available on the WorkBench BBS which
can be downloaded using the name OMAM_200.ZIP.
RASMAM uses script files to direct it's actions. To use RASMAM for
maintenance, the following batch file could be used:
REM - first purge the message areas
REM - "purge.mam" is the file that controls the purging
REM
RASMAM purge.mam
REM
REM - then run EchoDor maintenance
REM - both EchoDor /M & EchoUtil /M will do it
REM
EchoUtil /M
REM
Page 47
EchoDor Version 3.11
3/16/92
REM - then renumber the message areas
REM "renum.mam" is the file that controls renumbering
REM
RASMAM renum.mam
In the above sample, two files are required for RASMAM. This is
PURGE.MAM which contains information on purging the areas and
RENUM.MAM which contains information on renumbering the areas.
EchoUtil will assist you in generating these files. Use one of the
following commands:
EchoUtil /RASMAM
EchoUtil /RASMAM nnn
EchoUtil /RASMAM ?
If you use the first command, EchoUtil will generate a PURGE.MAM file
and a RENUM.MAM file (both in the current directory). All message
areas will be purged to contain 100 messages.
If you use the second command, EchoUtil will generate the PURGE.MAM
and RENUM.MAM files which will maintain all message areas with "nnn"
number of messages. The "nnn" value may be from 1 to 255. Any number
outside this range will cause EchoUtil to use 100.
If you use the third command, EchoUtil will generate the PURGE.MAM and
RENUM.MAM files for all message areas. It will ask for the number of
messages to keep in each area as the files are generated. Any number
may be used.
These files may be edited after they are created to include any
special processing which can be provided by RASMAM.
Note:
EchoUtil will not check to see if you already have either of
these two files in the current directory. It will just overwrite
them if they are out there. Also, be sure that the TAG in the
AREATABLE is unique for each area. This "TAG" is used when
generating the PURGE.MAM and RENUM.MAM files for naming the
areas.
Page 48
EchoDor Version 3.11
3/16/92
EDorPurg
The EDorPurg program can perform the message purge, renumber, relink, and
user file updates in a single operation. EDorPurg also compresses your
message directories and puts all the messages in numerical order within the
directory. Performing this operation has the advantage of keeping EchoDor
running fast.
Setup
If your using EDorPurg with EchoDor you should setup an EDorPurg.Cfg file.
This file contains a list of all the areas and what action should be
performed on that area. This parameter file is not required; however,
after it is set up, you only need to enter EDorPurg with no parameters and
your system will be purged.
The EDorPurg.Cfg file is a plain ASCII text file. Each area occupies one
line. Parameters are space delimited (one or more spaces between each
parameter).
The first parameter on the line must be the "TAG" name of the area. This
"TAG" name must match the "Area Tag Name" in the EchoDor.Ctl file.
Optionally the "TAG" name can match the area name that is listed in your
AREAS.BBS file.
The next parameter tells EDorPurg the type of area. The valid values are:
LOCAL
NETMAIL
ECHO
EDorPurg checks to make sure that the type specified matches the type in
the EchoDor.Ctl file. If the don't match, a warning is issued and EDorPurg
will use the type specified in the EchoDor.Ctl file.
All other parameters can be in any order. There should be only one
occurrence of each parameter per line. The following are valid parameters:
KEEP nnn
This indicates the number of messages to keep in the area. This parameter
will always take priority over all other parameters. For example, if you
specify KEEP 50 and KILLRECEIVED, after processing there will be only 50
messages in the area. EDorPurg will first kill received messages, then it
will trim the area to 50 messages.
FDAYS nnn
This indicates that files that are older than 'nnn' days old should be
purged. This parameter is based on the date of the *.msg file.
MDAYS nnn
Page 49
EchoDor Version 3.11
3/16/92
This indicates that messages that are older than 'nnn' days old should be
purged. This parameter is based on the date of the message.
KILLRECEIVED
This indicates that messages that have been "received" should be deleted.
An example of a purge line might be:
NetArea NETMAIL KEEP 75 KILLRECEIVED
or
EchoArea ECHO KEEP 150 MDAYS 30
After you have set up your EchoDor.Ctl file, you can have EchoUtil build
you an initial EDorPurg.Ctl file. To build this file enter:
EchoUtil /EDorPurg
EchoUtil /EDorPurg 150
EchoUtil /EDorPurg ?
The first example will generate an EDorPurg.Ctl file for every area with a
KEEP 100 value.
The second example will generate an EDorPurg.Ctl file for every area with a
KEEP 150 value.
The last example will generate an EDorPurg.Ctl file for every area and will
ask for the KEEP value.
After you generate the EDorPurg.Ctl file you can use an editor to make
additional changes.
Be sure you have a blank line after the last entry in the EDorPurg.Ctl
file; otherwise, you'll get strange messages about the last area.
Note:
EchoUtil will not check to see if you already have an EDorPurg.Ctl file in
the current directory. It will just overwrite it if is out there. Also,
be sure that the TAG in the AREATABLE is unique for each area. This "TAG"
is used when generating the control file for naming the areas.
Page 50
EchoDor Version 3.11
3/16/92
EDorPurg Parameters
EDorPurg has a number of command line parameters to help tailor its
operation to your needs.
Note:
Some of the parameters use the same letter to mean different things.
If the letter is followed by a parameter then it means one thing, if
the letter is used without any parameter it means something else.
For example:
-e<file> specifies the path and file name of the EchoDor.Ctl file.
-e (without the file name) specifies to process only echo
areas.
The following command line parameters are available:
-a specifies that EDorPurg should process all areas except
passthru areas. This parameter is most useful when using
EDorPurg with an Areas.BBS file.
-a<file> specifies that EDorPurg should use an AREAS.BBS file in
place of an EchoDor.Ctl file. The <file> parameter
specifies a full path and file name of the AREAS.BBS file to
be used.
To specify a local only area using an AREAS.BBS, specify the
area tag and path only. Do not specify any nodes.
To specify a net mail area, use the tag name NETMAIL.
-d<dir> This tells EDorPurg to purge messages in the specified
directory. Do not put <> around the directory name. When
using the -d<dir> command line parameter, you must also use
-e, -n, or -l command to indicate the area being echo, net
mail, or local.
-e This parameter tells EdorPurg to process only echo areas.
Net Mail and Local areas will not be purged. When used with
the -d<dir> command, this parameter tells EDorPurg that the
area being processed is an Echo area.
-e<file> This parameter tells EDorPurg the path and name of the
EchoDor.Ctl file to be used. If the -e<file> parameter is
not specified, EDorPurg will look for a control file named
EchoDor.Ctl file in the current directory. Do not put <>
around the file name.
-K<nnn> This parameter tells EDorPurg the number of messages to
keep. The 'nnn' should be replaced with a number. Do not
put <> around the number. For example:
-K150
Page 51
EchoDor Version 3.11
3/16/92
would tell EDorPurg to keep 150 messages in the area.
-KRECV This parameter tells EDorPurg to kill received messages.
-l This parameter tells EDorPurg to process only local areas.
Net Mail and Echo areas will not be purged. When used with
the -d<dir> command, this parameter tells EDorPurg that the
area being processed is a local area.
-l<file> This parameter tells EDorPurg the name of the log file where
purging information should be placed. Do not put <> around
the file name. If this parameter is omitted and a LOG
filename parameter is in the EchoDor.Ctl file, that log file
will be used.
-n This parameter tells EDorPurg to process only net mail
areas. Local and Echo areas will not be processed. When
used with the -d<dir> command, this parameter tells EDorPurg
that the area being processed is a net mail area.
-p This parameter tells EDorPurg to only purge the areas. No
renumbering should be done.
-q This enables "QUIET" mode. Very little output will be
displayed to the screen. This does not effect output to the
log file.
-r This parameter tells EDorPurg to renumber only. No purge of
the area will be done.
-REC Force recovery of areas. If this parameter is specified,
EDorPurg will only operate on errors that need to be
recovered. No other operation will be performed. This
parameter is usually not required as EDorPurg can figure out
for itself that it should recover.
-s<file> This parameter specifies a file that contains tag names of
the areas that should be purged. Do not put <> around the
file name.
-t<tag> This parameter specifies a single area by tag name. Do not
put <> around the tag name.
Page 52
EchoDor Version 3.11
3/16/92
Operation
EDorPurg does not operate as most message renumbering / purging utilities
run. The following is a summary of the way EDorPurg performs its
operation. This information is provided for the curious.
EDorPurg first counts the messages in the directory to be purged. It also
checks to see if any other indicators (such FDAYS) has been specified and
checks all messages to see if it should be kept.
If messages are to be purged, a new directory is created. This directory
is named the same as the original directory with the exception of an
extension of @@@.
EDorPurg writes a recovery file to the new directory. This recovery file
contains a list of the old message numbers, what the new message numbers
will be, and relinking information.
The messages that are to be kept are renamed into the new directory. This
renaming moves the message from one directory to another (this is not a
copy but a move) and sets the name of the message to its new number.
All old messages remaining in the original directory are erased.
Any file that remains in the old directory (such as ORIGIN or LASTREAD) is
moved to the new directory.
The old directory is removed.
The new directory is renamed so it's name will be the same as the old
directory.
The next/prior message numbers are then relinked.
The EchoDor user file last read pointers are updated.
Any 'LASTREA?' files are updated.
The recovery file is erased.
Page 53
EchoDor Version 3.11
3/16/92
Recovery Method
EDorPurg contains complete recovery should some problem prevent it from
completing its purge / renumber operation. With most purging / renumbering
utilities, should some problem strike during the purge/renumber operation,
your left with a mess in the directory and users last read pointers are
left pointing into who knows where.
To combat this problem, EDorPurg writes recovery information to a file
called EDorPurg.REC. This file contains complete information about the
state of the message area before the purge and how the renumbering will
effect user last read pointers.
Should a problem occur where EDorPurg is not able to complete its
operation, just restart EDorPurg. It will automatically recover the area
that it was unable to complete. If you only want EDorPurg to recover and
not to purge other areas, start EDorPurg with the -REC parameter.
Page 54
EchoDor Version 3.11
3/16/92
FastLink
FastLink is a program which relinks the prior message / next message
pointers by subject. This allows the reader to use the +, -, and * options
on the read command.
Parameters
FastLink has a number of command line parameters to help tailor the
operation to your needs.
Note:
Some of the parameters use the same letter to mean multiple things.
If the letter is followed by a parameter then it means one thing, if
the letter is used without any parameter it means something else. For
example:
-e<file> specifies the path and file name of the EchoDor.Ctl file.
-e (without the file name) specifies to process only echo
areas.
The following command line parameters are available:
-a specifies that FastLink should process all areas except
passthru areas. This parameter is most useful when using
FastLink with an Areas.BBS file.
-a<file> specifies that FastLink should use an AREAS.BBS file in
place of an EchoDor.Ctl file. The <file> parameter
specifies a full path and file name of the AREAS.BBS file to
be used.
To specify a local only area using an AREAS.BBS, specify the
area tag and path only. Do not specify any nodes.
To specify a net mail area, use the tag name NETMAIL.
-d<dir> This tells FastLink to relink messages in the specified
directory. Do not put <> around the directory name.
-e This parameter tells FastLink to process only echo areas.
Net mail and Local areas will not be purged.
-e<file> This parameter tells EDorPurg the path and name of the
EchoDor.Ctl file to be used. If the -e<file> parameter is
not specified, EDorPurg will look for a control file named
EchoDor.Ctl file in the current directory. Do not put <>
around the file name.
Page 55
EchoDor Version 3.11
3/16/92
-l This parameter tells FastLink to process only local areas.
Net mail and Echo areas will not be purged. Normally this
parameter will not be used. EchoDor keeps messages in local
areas properly linked regardless of the subject. Use this
parameter with care.
-l<file> This parameter tells FastLink the name of the log file where
purging information should be placed. Do not put <> around
the file name. If this parameter is omitted and a LOG
filename parameter is in the EchoDor.Ctl file, that log file
will be used.
-n This parameter tells EDorPurg to process only net mail
areas.
-q This enables "QUIET" mode. Very little output will be
displayed to the screen. This does not effect output to the
log file.
-s<file> This parameter specifies a file that contains tag names of
the areas that should be purged. Do not put <> around the
file name. When using FastLink after mail is tossed, this
parameter will tell FastLink exactly which mail areas need
to be processed.
-t<tag> This parameter specifies a single area by tag name. Do not
put <> around the tag name.
Page 56
EchoDor Version 3.11
3/16/92
Operation
Normally FastLink is used only on Echo areas. Net mail is usually a number
of disjointed messages. Local message bases keep by EchoDor will always be
properly linked.
After Tossing Mail
The best time to run FastLink is immediately after you have completed
tossing in coming mail. Most mail tossers will write a file
containing the names of the Echos that have been tossed. Use this
file with the -s<file> parameter to have FastLink relink only the
message bases that have received messages.
If your tosser cannot write a scan file, just run FastLink with the -e
parameter after receiving mail. FastLink will scan each area and
relink only areas that have not been processed. Although this
operation is not as fast as using the -s<file> parameter, it's still
pretty quick.
If you run FastLink from a directory other than the EchoDor directory,
you will need to specify the location of the EchoDor.Ctl file. Use
the -e<file> parameter. When running FastLink without a scan file (as
described above) the command line parameter will be:
FastLink -eC:\Path\EchoDor.Ctl -e
There are two -e parameters, one with a file name (indicating the
location of EchoDor.Ctl) and another indicating process only echo
areas.
After EDorPurg
If you do not want to run FastLink after receiving mail, the next best
place to run is immediately after purging / renumbering with EDorPurg.
Do not confuse the "relinking" phase of EDorPurg with the operation
performed by FastLink. EDorPurg updates the prior / next message
pointers with the new message numbers (after renumbering). FastLink
relinks messages based on subject.
It is faster to run FastLink after running EDorPurg than before. This
is because:
1. There are less messages that have to be checked.
2. EDorPurg has updated already linked messages so FastLink
won't have to rewrite these messages.
3. EDorPurg will have less messages to link because messages
not yet linked will not require updating.
It is again suggested that only Echo areas be processed by FastLink.
The command line to do this is:
Page 57
EchoDor Version 3.11
3/16/92
FastLink -e
or if you need to specify the location of the EchoDor.Ctl file:
FastLink -eC:\path\EchoDor.Ctl -e
Page 58
EchoDor Version 3.11
3/16/92
EchoDor Operation
EchoDor operation is simple. It has been designed to look like part of
your BBS. The menu files can be changed to look like the rest of your
system as well. The command letters may NOT be changed.
Menu Commands
The valid commands from the main menu are as follows:
J - Join Conference
A - Area Change
When this function is selected, the user is presented with a prompt
asking for the echo mail area number, or the name, or 'L' to list the
areas. If you have defined a description table in your EchoDor.Ctl
file, the description table will be listed. If you are using the
USERAREAFILE and the SYSOPAREAFILE parameters, the corresponding file
will be displayed. If graphic versions of the file exist, they will be
displayed if the user supports ANSI or ASCII graphics.
If your BBS system uses the term area instead of conference, modify
the menu to say [A]rea Change. EchoDor will except either J or A to
change conferences.
C - Check Personal Mail
When this function is selected, the user is presented with a prompt
that asks him/her to verify that mail is to be checked. During the
check, only conferences that have been selected in the IGNORE EDITOR
will be checked. The user can abort the scan at any time by pressing
'S'. When a message is found, the header information will be
displayed.
F - Toggle Full Screen Editor
This function allows the user to turn the full screen editor on or off
regardless of his/her graphics setting. See the FULL SCREEN EDITOR
reference section for instructions for its use.
H - Invoke the Help System.
This displays the help menu to the user. See the HELP SYSTEM
reference section for information of the help system.
I - Ignore Editor.
This editor allows the user to include or exclude any conference from
the 'check personal mail', 'check new messages', or 'Pack mail'
functions.
L - Leave Sysop a Comment.
Page 59
EchoDor Version 3.11
3/16/92
This option lets the user enter a message into the comment area. This
option is not valid if the NOCOMMENT parameter is specified. If you
decide to disable comments, you should edit the echo menus to remove
the option.
P - Pack Mail section.
This function allows the user to enter the Pack Mail section. Within
this section the user can pack mail for download.
R - Read Messages.
This function allows the user to read & reply to the messages in the
current echo mail area. The user is presented with a sub-menu of
options after each message is displayed.
S - Scan Messages.
This function allows the user to display a list of message headers.
(IE: To....From....Sbj) Etc.
E - Enter a Message.
EchoDor users may select a line editor much like most BBS's, or a full
screen editor. This full screen editor is the same editor found in
PRODOOR. (The PCBOARD Door). See the full screen editor section for
more information.
X - Expert Toggle.
This turns on and off the main menu display. Just like most BBS's.
Q - Quit EchoDor.
In local mode this function will return you to the DOS prompt. In
On-line mode, this function will return the caller to the BBS.
Z - Sysop commands.
This function enters the SYSOP menu. From the SYSOP menu you may Copy
or Doctor messages, read the nodelist or check EchoDor users.
If you can't get to the sysop menu and you are a sysop, use EchoUser
/S and set your SYSOP flag in your user record. Read the section on
EchoUser.
Reading messages
After activating the read message command (R), you will then be shown the
message in the area where your last read pointer is set. At the bottom of
the screen, a prompt line will be shown which will give you a set of
options. Each option is selected by typing the first letter of that
option. You may also select a specific message to be displayed by entering
Page 60
EchoDor Version 3.11
3/16/92
the message number of the desired message in place of an option letter. If
the message is public or address to you or from you, it will be displayed.
Page 61
EchoDor Version 3.11
3/16/92
Entering messages
There are two ways to enter messages:
1) With the full-screen editor.
2) With the line editor.
Each of these methods will be described separately. If you are using IBM
ANSI graphics, then the full screen editor will be chosen for you. If not,
then the line editor will be chosen.
Line Editor
The line editor is the simplest of the two editors. You are initially
placed in "entry mode" where you will just have to type your message. The
lines will be wrapped automatically for you. You press enter at the
beginning of a line to leave "entry mode". After leaving "entry mode", you
will be presented with a small menu consisting of these options:
[C]ont
Continue the current message. This will simply place you back into the
line editor's "entry mode" at the end of the last line you entered.
[I]nsert
This will allow you to insert a line anywhere into the message. When
you select this option the line editor will ask you where you want to
insert the line.
[D]elete
This option will let you delete any line in the message. When you
select this option you will be asked the starting and ending line(s)
you want to delete.
[V]isual
If you are using ANSI graphics, this will let you re-enter the full
screen editor.
[Q]uote
If you are entering a reply, you may quote lines directly from the
original message. When you select this option you will be given
another small menu which will allow you to:
List the original message.
Specify the starting line number to quote.
Specify the ending line number to quote.
Display the message your current writing.
Page 62
EchoDor Version 3.11
3/16/92
Specify the line where the quoted lines are to be inserted.
[A]bort
This will throw the message that your are currently entering away and
exit the line editor.
[S]ave
This will save the message you are entering and will exit the line
editor.
Page 63
EchoDor Version 3.11
3/16/92
Full Screen Editor
The EchoDor full screen editor is the same editor that appears in PRODOOR
(Thanks Sam!). It provides full-screen editing for on line message entry.
Full screen editing requires ANSI terminal emulation. The full screen
editing commands are WordStar-Like control characters. If your terminal
program provides ANSI keyboard emulation, you will also be able to use the
indicated function keys. Here is a summary of the editor commands:
<< Cursor Motion >>
Ctrl-S Move left 1 character (Left arrow key)
Ctrl-D Move right 1 character (Right arrow key)
Ctrl-E Move up 1 line (Up arrow key)
Ctrl-X Move down 1 line (Down arrow key)
Ctrl-A Move left 1 word
Ctrl-F Move right 1 word
Ctrl-I Tab cursor to next tab stop (Tab key)
Ctrl-P Move cursor to line end (End key)
<< Scrolling >>
Ctrl-R Move up a page (PgUp key)
Ctrl-C Move down a page (PgDn key)
<< Delete >>
Ctrl-G Delete character under cursor
Ctrl-H Delete character to the left of the cursor
(Backspace)
Ctrl-T Delete the word following the cursor
Ctrl-Y Delete the current line
Ctrl-J Join current line with next line
<< Miscellaneous commands>>
Ctrl-B Reformat paragraph. A paragraph ends with the first line that is
blank or that has leading spaces.
Ctrl-K Visual quote mode. This allows you to display the original
message and copy lines from it to the current message.
Ctrl-L Clear screen and re display. (Home key)
This also scrolls the screen so the cursor line is in the middle
of the display.
Ctrl-N Insert a RETURN. Splits line at the cursor.
Ctrl-O Review the text of the Original message you were reading or
replying to. If your not replying to a message this key does
nothing.
Page 64
EchoDor Version 3.11
3/16/92
Ctrl-Q Visual quote mode. This allows you to display the original
message and copy lines from it to the current message.
Ctrl-V Toggle insert/over type mode. (Ins key)
ESC Exit visual mode and return to the Message Entry Command prompt.
Page 65
EchoDor Version 3.11
3/16/92
Insert Mode versus Over type Mode
In insert mode, all characters typed are INSERTED before the cursor. The
ENTER key splits the line and BACKSPACE can re-join lines.
In over type mode, characters "type over" what was on the screen before.
Over type mode also disables the automatic line SPLIT / JOIN available in
insert mode. Use ^N(split) and ^J(join) to manually split and join lines
while in over type mode.
Keyboard emulation
The easiest way to control the cursor in Visual Edit mode is to use your
cursor keys. Most popular terminal programs provide some sort of keyboard
emulation. Unfortunately, this emulation is either incomplete or requires
you to go through an involved configuration process.
The WordStar* command set was chosen as a control-character command set
because it can function on virtually any keyboard and with any terminal
emulation mode. It also has the advantage of letting you keep your fingers
on the "home" keys while moving the cursor around.
Page 66
EchoDor Version 3.11
3/16/92
Visual Quote
EchoDor now has Visual Quote. This allows users of the full screen editor
to more easily quote from a message. The use of Visual Quote is intuitive.
The first time Ctrl-Q or Ctrl-K is pressed the original message is
displayed to the user. The user then uses the up and down arrow keys or
the page up and page down keys to move the cursor to the line to be quoted.
Then the space bar is pressed. A tag indicator is placed to the left hand
side of the line and the cursor is moved to the next line. The user may
tag as many lines as desired. When all the desired lines are tagged press
Ctrl-Q or ESC to return to the message being written.
To insert the lines tagged press Ctrl-Q or Ctrl-K again. A message will
appear at the bottom of the screen saying:
[I]nsert quote or [T]ag:
If "I" is pressed the tagged lines will be inserted into the message above
the current cursor line. If "T" is pressed the user is returned to the
original to allow tagging a new set of lines.
If you use the NEWQUOTE option in the EchoDor.Ctl file, after the user tags
the lines to be quoted, EchoDor will insert the lines immediately before
the cursor.
EchoDor pays particular attention to the reformatting of inserted lines.
Each inserted line is preceded by "xx>" with "xx" being the initials of the
person being quoted. Every line within a paragraph is adjusted to make it
correctly fit in the message. Blank lines and paragraph structure will be
maintained.
Page 67
EchoDor Version 3.11
3/16/92
Using EchoDor Locally
EchoDor also works very well as a local message reader. To use it in this
manner, start EchoDor with a batch file something like this:
rem
rem Set the directory and drive first
rem
C:
cd \EchoDor
rem
rem Now start EchoDor as the sysop -- this is much like
rem local mode but it will log you on with the name you
rem specified as the sysop.
rem
ECHODOR /S
rem
rem Check for mail to be sent, the name of the SCANLOG.TXT
rem file would depend on your configuration.
rem
rem
IF NOT EXIST SCANLOG.TXT GOTO EXIT
rem
rem Now run the mail packer/scanner (could be ConfMail).
rem
QM SCAN PACK <what ever commands you need>
rem
rem we're all done
rem
:EXIT
Page 68
EchoDor Version 3.11
3/16/92
Special local keys
While the user is on line, EchoDor provides some additional functions to
the SYSOP.
ALT-I System Information
This provides the following information:
Baud Rate
Local flag
Graphics Setting
Time Left
Com Port
User Name
Access Level
Time credit
Time left
Node Number
ALT-C Forced Chat
When ALT-C is pressed, the user is placed into CHAT mode. EchoDor
does not provide a split screen chat.
To exit chat the SYSOP must press <esc>.
ALT-D Drop to DOS
This allows the SYSOP to drop to DOS for those Quick checks and fixes.
Up Arrow
This will add 2 minutes to the users time.
Down Arrow
This will subtract 2 minutes from the users time.
Page 69
EchoDor Version 3.11
3/16/92
Message Header Description
Every message in the system contains control information along with the
text that is entered by the user. The sysop using EchoDor can modify the
information in this header using the Doctor command (Z on the main menu
then D). The following fields can be modified:
A. From
This field contains the name of the person that entered the message.
B. To
This field contains the name of the person that is to receive the
message.
C. Subject
This field contains the subject of the message. In the case of a file
request or file attach type message (see below) this field contains
the file name that is being attached or requested.
D. Date/Time
This is the date and time when the message was entered. The format of
this field must be:
16 Jan 90 13:01:05
E. Origin
This is the zone:net/node.point number that originated the message.
This field is not used with local messages (Type B).
F. Destination
The is the zone:net/node.point number where the message is going.
This field is not relevant in echo message (Type E or I) or in local
messages (Type B).
G. Cost
This is amount of money it costs in cents to send the message. This
information is retrieved from the node list. This field is not used
for echo messages or local messages.
H. Reply
When a person enters a reply this is the message number to which
he/she is replying. When the message is an initial entry, this field
will be zero.
I. Next-Reply
When a person enters a reply this field is set in the original message
to the message number of the reply. When the message is an initial
entry, this field will be zero.
This field has a special use for echo mail. Message number 1 in an
echo area is usually used by the mail processor (ConfMail or QM) to
point to the highest message that has been scanned. Message number 1
is usually refereed to as the "high water mark". This field contains
the message number of the highest message scanned.
Page 70
EchoDor Version 3.11
3/16/92
J. Private
Messages in all areas may be marked private. If this flag is set to
"Yes" then only the sender, the receiver, and the sysop may read the
message. Although not allowed in most echoes, EchoDor does support
private echo mail messages if present.
K. Crash
This flag is used to tell the mail processing program to try to get
the message sent as soon as possible. Some mailers refer to this type
of mail as contentious mail.
L. Sent
This flag is set by the mail processor to indicate that the message
has been bundled to be sent. This flag does not indicate that the
message has actually left your system.
M. File Attach
Some messages are sent with a file. If this flag is set to "Yes" then
the subject field will contain the full path name of the file(s) to be
sent with the message.
N. Kill-Sent
After a message is sent, it is usually left in the area from where it
came. If this flag is set to "Yes" then the message will be delete
after it is bundled by the mail packer.
O. Local
This flag is set to "Yes" if the message was entered on your system.
If the message came from some other system this flag will be set to
"No".
P. F'req
This is a file request flag. If set to "Yes" then the subject line
contains the name of a file that you want sent to you from the
destination system. Files listed in this type of message should not
contain path names.
Page 71
EchoDor Version 3.11
3/16/92
How do file-requests work?
When a file request is generated, two files are created and placed in the
outbound directory. The first file contains the name of the file(s) that
you are requesting from the remote system. The second file specifies how
and when the transfer will take place. (i.e. crash-mail, normal, direct,
etc.). The stem for each of these files is made up of two four-character
hexadecimal numbers specifying the net and node number that the request
will be sent to.
The first file created is the .REQ file. If this file already exists then
it will be appended to. The name of the file being requested is simply
placed in the file in plain ASCII.
The second file created will have the extension of ".FLO", ".CLO", ".DLO",
or ".HLO". This tells the front-end processor how and when the file will be
transferred. The various methods are summarized below:
Name Ext Description
----------- ---- -----------------------------------------------
Normal FLO Normal transfer. It will occur at the time you
specify in your mailer program. Normal
requests can also be "routed" by your mailer
program.
Crash-Mail CLO The request will be processed at the earliest
possible time.
Hold HLO Hold-for-pickup. The remote system must poll
(call) your system in order to receive the
request.
Direct DLO This is a direct request. It will occur at the
time you specify in your mailer program;
however, this request must go directly to the
specified address and cannot be routed.
EchoUtil generates file-requests with the "/GET" option. On the command
line, you simply need to specify the filename and the node that you want to
request from.
Examples:
EchoUtil /GET echo308.arc from 300/9
This generates a file request to a system for the file "ECHO308.ARC".
It will send this request to node 300/9. Since no other method was
specified, it will default to normal and generate a ".FLO" file for
the request (as well as a .REQ file). This transfer will take place
at national mail hour.
EchoUtil /GET echo308.arc from 300/9 C
Page 72
EchoDor Version 3.11
3/16/92
Like the above example, this will request the file "ECHO308.ARC" from
300/9, but it will generate a ".CLO" file instead of a ".FLO" file.
Therefore, this transfer will take place at the soonest available
time.
EchoUtil /GET ECHODOR from 300/9 H
This example demonstrates a "magic" request. Magic requests are
special type of request where you specify a magic file name (in this
case, "ECHODOR"). The file must be set up as a magic file on the
receivers end as well. The advantage to a magic filename is that the
sysop usually has it reference the most recent version of the file you
are requesting -- that means you don't have to worry about the exact
version number/filename. The "H" on the line specifies that the
request will be marked as hold-for-pickup. The request will not be
sent out at all and the remote system must call your system for the
request to be processed. (This is not usually done).
EchoDor can also do file requests with net mail. To enable this feature
set the 'F' flag on your net mail description line within the area
description table to 'Y'. Each time you enter a message in the net mail
area, EchoDor will ask if you want to do a file attach or file request. If
you answer "R", meaning request, EchoDor will prompt you for a file name.
Enter only the file name and extension of the desired file. EchoDor will
then precede with the net mail message entry.
Page 73
EchoDor Version 3.11
3/16/92
File-attaches
A file attach is a method of sending a file from your system to any remote
system. It is very similar to the file-request feature in operation, but
no .REQ file is generated. Instead, the filename and path is placed in the
FLO/CLO/DLO/HLO file.
EchoUtil generates file-requests with the "/SEND" command line option. The
syntax is very similar to file-attaching with a few differences shown in
the examples below.
Examples:
EchoUtil /SEND c:\files\echo308.arc to 300/9
This sends the file echo308.arc to node 300/9. The file will be
defaulted to normal (.FLO) and sent at national mail hour. The file
to be sent (Echo305.arc) is located in the C:\Files directory. This
an important difference from File-requesting -- With a file-attach,
you MUST specify the full path of the file.
EchoUtil /SEND c:\files\echo308.arc to 300/9 C
This is the same as the above option except the mail will be set to
crash-mail (.CLO) and sent at the first available time.
EchoDor can also do file attaches with net mail. To enable this feature
set the 'F' flag on your net mail description line within the area
description table to 'Y'. Each time you enter a message in the net mail
area, EchoDor will ask if you want to do a file attach or file request. If
you answer "A", meaning attach, EchoDor will prompt you for a file name.
Be sure to enter a fully qualified path name (include the drive and
directory). EchoDor will check for the existence of the file and if found
will continue with the entry of the message.
Page 74
EchoDor Version 3.11
3/16/92
Listing file-requests and file-attaches
EchoUtil has the capability to produce a summary of all of your file
requests or attaches that are presently in your outbound directory.
Note:
This will only with with "BINKLEY" type systems.
To produce a list of current outbound file-requests:
EchoUtil /REQLIST [INTO <filename>|PRINTER]
The INTO parameter is optional and if specified will allow you to send
the list to either the printer or a disk-file.
To produce a list of all outbound file-attaches:
EchoUtil /ATTACHLIST [INTO <filename>|PRINTER]
The INTO parameter functions the same as above. upon the execution of
this command, EchoUtil will list all of the file-attaches excluding
normal ArcMail packets (.MOx Files).
Page 75
EchoDor Version 3.11
3/16/92
Auto Messages
The "auto message" ability of EchoDor is a very powerful feature that
allows you to post news updates about your system in a special area. When
a user calls your system, all of the "auto messages" that he has not read
will be displayed to him. EchoDor will still honor private messages. If
the message is set private then only that user (and any sysop) will see the
message. Since the "auto message" area is treated by EchoDor as a normal
mail area, it is very simple to enter "auto messages".
To set up an auto message area, simply create a directory like you would
for any other mail area. Then, add an entry to EchoDor's area table for
the auto message area. The entry should be just like a regular message
area except set it's type to "A" for auto message. You should also set it
to sysop-only to prevent your users from posting in it.
You have two ways to use the "auto message" feature. The first and
simplest way is to do nothing. When the user enters EchoDor, any auto
messages that the user has not seen will be displayed to him/her.
The second way requires you to set your BBS to shell out to EchoDor during
the users logon process, preferably right after he checks his mail. With
RBBS you specify EchoDor as the "Door Program to check users at logon".
This is in the "doors setup" section. You need to call EchoDor with either
"ECHODOR Node-num /AUTO" or "ECHODOR Node-num /AC" where node-num is the
same as the node-number use when you call EchoDor as a door. The "/AUTO"
option will simply display all new "auto messages" and the "/AC" option
will display all auto messages and then ask the user if he wishes to check
for new echo mail messages. This second method allows you to use EchoDor
to display messages to all users regardless of them entering EchoDor to
read mail.
Page 76
EchoDor Version 3.11
3/16/92
General information
1. Commands can be stacked (r;123 for read message #123, a;2;r;4;q;a;3
switch to area #2, read message 4, quit to main, and switch to area
#3).
2. There are 5 command switches:
/L load up the door in local mode.
/S run the door locally and log in the sysop.
/H get help about the switches.
/R return to running EchoDor
3. The system will check for loss of carrier and out of time. If either
condition occurs, EchoDor will return back to your BBS. All user
information will be saved before exiting.
4. A user will not be kicked off due to time in the middle of a message.
5. You should only log on for a maximum of 120 minutes at a time. You
might be able to log on longer, but the elapsed time functions might
have some trouble.
6. You MUST have a fossil driver to run this door, I suggest X00, but
OpusCom or BNU should work just as well.
7. If you run net mail you must provide a version 6 nodelist. The
nodelist must be compiled with zone information. If you use Parselst
be sure to include the "UseZones" command.
Starting with v3.10a of EchoDor, registered users can use the new
EchoDor format nodelist. This format is most useful for people that
run Front Door or D'Bridge. This new format uses index files and the
"raw" nodelist files.
8. Messages with more than 512 lines will be truncated by EchoDor.
9. Messages larger than 32K will be truncated by EchoDor.
10. Message areas may not contain more than 5000 messages. Areas with
more than 5000 messages will lose their last message pointers when
renumbered.
Page 77
EchoDor Version 3.11
3/16/92
EchoUser Program
The EchoUser program allows modification of special control information
used by EchoDor. The EchoUser program uses the same DoorDriv.Ctl and
EchoDor.Ctl file as EchoDor and may be run remote (through the modem).
User File Records
The EchoDor user file contains two different types of records.
Default User & Maintenance Record
The first record in the file is called the Default User & Maintenance
record. The record contains information used by EchoDor when setting up
new users. Note that changing fields in the Default User & Maintenance
record will not alter currently active users.
The following fields are important during new user setup:
Graphics Mode
Some BBS systems do not pass graphics information to EchoDor that
works properly. This will cause some users to get garbage on their
screens. If the default Graphics mode (Graphics in the Default
record) is set to some value other than default, that value will
override the value that is passed by the BBS. You can then instruct
the users to set their graphics level from the user menu.
Default Hot keys
Some sysops like hot keys some do not. The value that is set for hot
keys in the Default record will be the value that every new user
receives. This value can be overridden by the user from the user
menu.
Restrict Message Areas
This is one of the most powerful features in the EchoDor / EchoUser
system. EchoDor normally controls access to different areas based on
the users security level. In many cases this method is adequate.
However, some sysops run special areas for their users. Using the
Restrict Message Areas, access to specific areas can be "Blocked".
Every new user will then be excluded from the "blocked" areas. The
"Blocked" will be as if they did not exist. There is no indication
given to the user that a blocked area is any different from a non
existent area.
Sysop Flag
The sysop flag cannot be altered in the Default User & Maintenance
record. New users will only be set to SYSOP if their name is in the
EchoDor.Ctl file.
Security Level
Page 78
EchoDor Version 3.11
3/16/92
Some BBS systems do not pass a security level to EchoDor, as an
example PC-Board will not pass a security level. By default EchoDor
uses the level 50 for these types of systems. In most cases this will
work fine; however, cases may arise where it would be better to use a
different security when users first use EchoDor. If the security
level in the Default record is set, that level will be used in place
of the BBS passed level.
Delete/Undelete
The delete/undelete flag cannot be changed in the Default User &
Maintenance record. This record can never be deleted.
The Default User & Maintenance record also contains a Date Last On. This
field is actually the last date when maintenance (EchoUtil /M or EchoUtil
/MAINT) was run.
User Records
All other records in the User file are regular user records. Using
EchoUser you can set specific access rights for individual users.
Graphics Mode
Normally you will not want to alter the value in this field for
specific users. Users can set this from the User Menu within EchoDor.
Altering this field will override the graphics information passed in
the Door Information file.
Default Hot keys
Again, this is a user controlled field and you will not normally want
to alter this for individual users.
Restrict Message Areas
Like using this in the Default User & Maintenance record, you can
"Block" or "Avail" (available) areas to specific users. If an area is
"Block", that user will not have any idea that the area exists.
Sysop Flag
Sysops can be indicated by having their name in the EchoDor.Ctl file.
Adding and deleting sysops in this way can become bothersome. The
SYSOP flag in a user record can be set to have EchoDor treat this user
like a sysop.
Security Level
If the Security level for an individual user is set, that security
level will be used in place of the security level passed by the BBS.
Another user for this, involves SYSOPS. When a sysop logs on locally
into EchoDor using the /S option, EchoDor defines a default security
level of 1024 for that user. This security level may not be high
enough for some setups. To override this 1024 value, enter a security
level for the sysop that is adequate.
Delete/Undelete
Page 79
EchoDor Version 3.11
3/16/92
The Delete/Undelete section is actually two specific functions. User
records in the EchoDor user file can be marked as deleted. When a
user is marked as deleted, that user record will NEVER be deleted by
EchoUtil. Anytime that user attempts to use EchoDor, he will be
denied access to the door.
The Undelete question will be asked if the user is deleted. If the
Undelete questions is answered Y, that user will be returned to a
normal user.
The NoDelete function is different from the UnDelete question. If a
user is marked NoDelete, that user will NEVER be deleted by EchoUtil,
and will always have access to the Door.
The last selection on the Menu is the User Record Selection section.
Before you can change information in a user record or in the Default User &
Maintenance record, the record to be changed must be selected.
When selecting the record, you first enter a name (or partial name) of the
user that you want to change. For the Default User & Maintenance record,
enter DEFAULT. EchoUser will then present you with a list of users that
match. The names will be preceded by a user number. EchoUser will then
ask for the user number to change. Enter the desired number of the user.
Then make the needed changes.
There is no need to save the changes as this is performed by EchoUser when
you either change users or exit the program.
Remote Operation
EchoUser can be run through the modem. The command line to run EchoUser
is:
EchoUser %1
^
|
+ This is replaced with the node number.
This is exactly the same way used for EchoDor.
Local Operation
To run EchoUser locally use the command line:
EchoUser /S
Which will start EchoUser with the SYSOP as fast logon.
Page 80
EchoDor Version 3.11
3/16/92
Using SCANMRG
The SCANMRG program is used to combine scan logs generated by EchoDor. A
scan log is a list of area names which contain new messages. Normally,
EchoDor generates a scan log file. That file is then processed by a mail
scanner program and outgoing packets are generated.
However, some people only want to run the scanner program once a day.
Other people run multiple nodes and only run the scanner from a single
node. People that run their boards in this manner need a way to combine
scan logs. That is exactly what ScanMrg does.
The first question you may ask is why not just use copy and append each log
to the end of a common file. Ideally if every area was only used once this
would work. But, through out the day people will enter multiple messages
in the same area. In these cases you want to have that area only listed
once.
That is the way SCANMRG works. First SCANMRG reads the output scan log
into memory. Then it reads each line of the input scan log and compares
the just read area name with all the other area names. If the name is new
SCANMRG adds it to the list. If it is already in the list, SCANMRG
discards the entry. When the last entry from the input file is read, all
the entries are written to the output file.
The format to use SCANMRG is:
SCANMRG infile outfile
Where "infile" is the just created input file.
And "outfile" is the combined scan logs. If SCANMRG is run and the
"outfile" does not exist, one is created.
Page 81
EchoDor Version 3.11
3/16/92
The EchoDor Nodelist compiler
Starting with version 3.10a, EchoDor now allows the use of two different
types of node lists. The first type of node list is known as a version 6
node list. This node list is most often used with BinkleyTerm mailers.
The second type of node list is exclusive to EchoDor. This node list uses
the St. Louis node list and three index files to allow rapid access to
entries in the node list.
This new node list is ideal for people who use Front Door or D'Bridge which
have proprietary node list structures. During a test the index files for a
full Fidonet node list took only 180k plus the size of the "raw" St. Louis
node list. This is much smaller than the 1 to 2 megabyte files created
when a version 6 node list is used.
The node list compiler can not apply node diff files. You must use a
separate program to apply the diff's.
How it works
The idea is based on doing a single line compile of the "raw" node list
when that line is needed. The only real problem with this is finding the
correct line to compile. The correct line is located by EchoDor through
the use of three files.
The first file is the EchoDIdx.Idx file. The structure of this file is
exactly the same as the NodeList.Idx file used in a version 6 node list.
This file contains all the net/node numbers that are in all the node lists
with special coding for zones and regions. The position of the desired
net/node number within this file allows EchoDor to locate the positional
information in the next file.
The positional information is used to read a specific record from the
second index file. This is the EchoDXId.Idx file. This file contains the
full zone, net, and node number as well as the node's hub. Also, two other
very important pieces of information is contained in the file. They are
the file number and the line position.
The file number is used to locate the name of the "raw" node list file
within the third file called EchoDNLx.Idx. This file is only used when the
node list file must be switched. The line position is then used to read a
single line of information from the "raw" node list file.
The single line of information from the "raw" node list is them compiled by
EchoDor "on the fly".
Even though the above procedure sounds very slow, EchoDor is able to
perform the operations quiet rapidly. You will notice very little
difference between the speed of a version 6 node list and the new EchoDor
node list indexing system. What you will notice is a lot of disk space
available that wasn't there before.
The Control file
Page 82
EchoDor Version 3.11
3/16/92
The control file directs EchoNLCP to the node lists that are to be compiled
and the directory that is to contain the index files. The following
commands are valid in the EchoNLCP.CTL file:
DIRECTORY <directory name>
This is the directory where the three index files (ECHODIDX.IDX,
ECHODXID.IDX, and ECHODNLX.IDX) are to be placed. This file does not
have to be in the EchoDor directory nor does it have to be in the same
directory as the St. Louis ("raw") node lists.
The <directory name> must match the NODELISTPATH parameter in the
EchoDor.Ctl file.
There can be only one DIRECTORY parameter.
NODELIST <Drive:\Path\Nodelist.fil>
This parameter tells EchoNLCP where to find the node list to be
compiled. The drive and path are optional; however, you should not
use "relative" directories (such as . (dot) and .. (dot, dot)).
If the nodelist file is specified using a wild card, such as
NODELIST.*, EchoNLCP will check all occurrences and compile the most
recent one. Be careful that it doesn't pick up a file that is not a
node list file. EchoNLCP will never attempt to compile a file that
has an extension of DAT, FDX or IDX.
You can specify as many NODELIST lines as needed to compile all the
node lists you use. The node list files do not all have to be in the
same directory.
NODELISTTYPE <V6>
NODELISTTYPE <ED>
This parameter is not really used by EchoNLCP, but is used by
EchoNLRD. This tells EchoNLRD which type of node list it should be
trying to read. The default is ED for EchoNLCP type node lists. The
V6 will allow EchoNLRD to read a version 6 node list.
Running EchoNLCP
EchoNLCP must be run anytime a change is made to any of the node list files
specified in the control file.
EchoNLCP cannot apply node diff files.
The command line to run EchoNLCP is:
EchoNLCP
or
Page 83
EchoDor Version 3.11
3/16/92
EchoNLCP cntlfile.ctl
The "cntlfile.ctl" file specification is optional. If not specified
EchoNLCP will look in the current directory for a file named EchoNLCP.CTL.
Operation of the compiler is very fast.
EchoNLRD node list reader
I have include a little utility which will allow you to read node list
information from the node list indexes generated by EchoNLCP. This is a
good check to see if all is OK as well as a "quickly" node list look up
utility.
To run EchoNLRD, go to the directory where the EchoNLCP.CTL file is located
and type EchoNLRD.
If you are not in the directory where then EchoNLCP.CTL file is located
type EchoNLRD Drive:\Path\EchoNLCP.CTL. This will start the reader and
tell it the file to use as a control file.
Page 84
EchoDor Version 3.11
3/16/92
Opus 1.1x Converter (OPUSCNVT)
This program is used to convert information in Opus SYSTEM##.DAT files to a
format usable by EchoDor. This utility takes two command line parameters.
The first is the directory where OPUSCNVT can find the SYSTEM##.DAT files.
The second parameter is the file that should be created by OPUSCNVT. For
Example:
OPUSCNVT C:\OPUS C:\EchoDor\Areatab.Txt
In the above example, OPUSCNVT will search the directory "C:\OPUS" for all
SYSTEM##.DAT files. After all the information is collected from the files,
OPUSCNVT will write a file called Areatab.Txt in the directory C:\EchoDor.
This file will only contain AREATABLE & AREADESC entries.
The following rules/exceptions are followed by OPUSCNVT:
If a SYSTEM00.DAT file exists it will be skipped.
All local areas will have a listed tag and an echo name of "Local".
All Net Mail areas will have a listed tag and an echo name of "Net mail".
The "No Public" flag is ignored.
If there is no separate write priv in the Opus area, Read Priv will be used
for WRACC.
File request will always be set "N".
After running OPUSCNVT you will edit your EchoDor.Ctl file. You would
insert a line something like:
INCLUDE C:\EchoDor\AreaTab.Txt
This would eliminate the need for you to transfer the information from the
created file to the EchoDor.Ctl file.
Page 85
EchoDor Version 3.11
3/16/92
Support for EchoDor
For support and registration you can reach me at:
Robert McCullough
P.O. Box 101095
Nashville, TN 37224
Voice Number 615 256-2444
BBS Support is available from:
The WorkBench BBS
Fidonet Node 1:116/1000.0
Rbbsnet Node 8:967/107.0
Nashville, TN 37210
The BBS Number is 615 256-2211
Available 23 hours a day.
9600 Hst
Note: We may be moving soon. We will still be in Nashville. Check
the node list for the correct number to use.
For registration and support in Europe you can call:
Chris Pelling
84 Heathcote Dr
East Grinstead
West Sussex
RH19 1ND
ENGLAND
BBS support in Europe is available from:
SDS Data Design's IBM BBS
Fidonet Node 2:254/41.0
Available 8pm-8am GMT
9600 Hst/DS/V42bis
011 +44 342 317 976
Information about EchoDor is also available in the National conference
ECHODOR. I understand that the conference is available on the Fidonet
backbone and the RBBSNet area. Please check with your net's National Echo
Mail Coordinator about the availability of this echo.
If you want to register EchoDor, please see the REGISTER.DOC file contained
in this archive.
Page 86
EchoDor Version 3.11
3/16/92
Revision History
3.11 revisions
EchoDor will now do a Confirm on [S]ave.
^A, SEEN-BY, and PATH lines were getting wrapped when using a MAXLINELENGTH
command. This has been corrected; however, ^A, SEEN-BY, and PATH lines
will always be displayed as full 72 character lines.
A problem was found in EchoNLCP causing it to skip nodes (yep, I finally
found a problem). This has hopefully corrected the problem.
Corrected a problem in EDorPurg that caused it to lose the high message
pointer in message #1 in echo areas.
Main menu can now do area "select". This includes changing areas by
number, and special commands <, +, -, >. You can not "select" an area by
name from the main menu, to select by name you must still use the [A] or
[J] command.
Comment area will now default to "PRIVATE" if the area allows private
message entry. To enable private messages in the comment area, set the "P"
flag in the AreaDesc table to Y.
Hopefully the problem with ^Z and ^A not working in the visual editor from
the remote end had been fixed.
EchoDor now does NOT include SOFT CR's (0x8d) in the message by default.
If you want EchoDor to include SOFT CR's in the message, add USESOFTCR to
the EchoDor.Ctl file.
Hot keys didn't work on the help prompt.
A request was made to "highlight" the one line menus. This has been done
so that users will have a better idea of what to do.
If you used the "restrict" option in the EchoUser program, it would not
restrict the user you were working on, but would restrict the logged on
user (the sysop).
EchoUser has new options. These include "Global restrict" and "Clear
Message area". Read the documentation for an explination of these options.
The "Command string" area was origionally limited to 40 characters. This
has been expanded to 80 characters. This will allow you to put more
information into the command string.
New EchoDor control option, VisualEsc. This allows you to define
characters (such as period (.) or slash (/)) which when typed in column 1
on the visual screen, will act the same as an esc. Makes Visual editor
even easer to use.
Page 87
EchoDor Version 3.11
3/16/92
If you want to use this add a line something like:
VISUALESC ./\
to the EchoDor.Ctl file. The three characters, period (.), slash (/)
and back slash (\) will if typed in column 1 act exactly was if the
user pressed the ESC key.
I have separated the [I]gnore sections for packing mail and for reading
messages. This will allow a user to have one setup for reading mail and
one setup for packing mail. For example, let's say there is a local echo
that the user reads and the traffic is small. The user can put that echo
in the [I]gnore option from the [U]ser setup menu. Then the user can go to
the [P]ack section and [I]gnore all ares except what he wants to pack if he
selects the Pack All Areas option.
The [I]gnore system can now except multiple numbers on the Activate area
and the Ignore area prompts. Multiple numbers are separated by spaces.
Removed the NOTIME parameter from the EchoDor.Ctl file. This parameter is
now available in the DoorDriv.Ctl file.
The registration of EchoDor is now controlled by a KEY file. If this file
is not present, EchoDor will beep and display the "Not registered" screen.
I have done this to make it easer for registered users to upgrade. Once
the EchoDor.Key file is in place, you won't have to get a new copy from me
... just copy the stuff into the directory and it will work registered.
Fixed a minor problem which would sometimes cause EchoDor to exit with an
error 005 if a user went into echodor then immediately exited.
Fixed the HCopy problem which would cause EchoDor to "lock up" if HCopy was
selected and you didn't have a printer attached to the computer or some
printer problem occured. EchoDor now writes to the printer using BIOS
calls and can detect if the printer goes off line or malfunctions.
I've reduced the memory requirements of EchoDor by using Overlays. I have
structured the overlays so that you should not see any loss of operating
speed. The current memory requirements of EchoDor is now 303k. Warning:
don't try to compress EchoDor with LZEXE or PKLite. It probally won't
work!!!
Fixed a problem which caused EchoDor to not go online when the sysop used
the DOOR.SYS (WC3.0 or GAP) drop file.
Improved the carrier detection scheme used in EchoDor. In older versions
if the user was displaying a large screen and the fossil didn't have enough
buffer to hold the entire file and the user dropped carrier, EchoDor would
hang. This has hopefully been corrected.
There was a problem when specifying a starting message number when packing
or scanning mail. EchoDor would always start on the message following the
specified number. This problem has been corrected.
Page 88
EchoDor Version 3.11
3/16/92
EchoDor can now swap itself out of memory when it does a "shell to dos".
To enable this feature add the parameter "SWAPFILENAME" to the DOORDRIV.CTL
file. Be sure to read the documentaton on this feature before you use it.
If swapping is enabled, memory requirements for EchoDor when you drop to
DOS is about 15k.
It has been requested to allow the SYSOP to configure the chat colors used.
Two new parameters in the DOORDRIV.CTL file will now allow you to configure
the colors used for chat. These are CHATUSERCOLOR and CHATSYSOPCOLOR.
EchoDor can now be told to reconize the GT embedded message codes. These
are ^E (pause then non-stop), ^R (non-stop), ^T (disable abort). The ^T
actually produces no action within EchoDor. To "turn on" this feature put
a G in the "P" column of the area table. The P column is becomming more
the type of messages allowed and less just a "private" flag.
EchoDor can now play music if it's embedded in the message. This will be
most useful when using ANSI GT messages.
It appears that some LANs have problem when files are opened in compability
mode on the network. I have made changes in EchoDor which will hopefully
improve LAN compability.
Problems were found using the Alias functions. EchoDor would not ask if
the user wanted to use an alias name during message entry. Also, sometimes
when the alias name was set, problems occured in the user menu.
When displaying a area list from the AreaDesc area (not from a file), the
"More ?" prompt would not allow the user to stop the entry. The "More ?"
prompt has been replaced with a "Continue Y/n ?" prompt which will allow
the user to stop the display.
When specifying areas to be [I]gnored, EchoDor would only allow a maximum
of 10 entries to be specified at one time. Some users were putting in long
lists of area numbers which would cause all entries beyond the 10th entry
to be skipped. This problem has been corrected. EchoDor will now allow as
many entries as the user specifies. I have also added a special entry
'ALL'. If the user enters ALL, every area will either be ignored or
activated depending on which one the user selected.
I found a problem in EDorPurg which would allow it to become confused while
relinking messages. This would be caused by a message that was incorrectly
linked (7 > 10 > 5) or (15 < 20 < 12) or (15 < 15). I have put extra
checking into EDorPurg which will cause it to break out of the link loop
should this type of condition occur.
When EchoDor recorded the number of times read, it would change the
date/time stamp of the message file. This would cause no problem unless
you tried to use the FDAYS option on EDorPurg. EchoDor will now preserve
the date/time stamp of the message file when updating the times read and
received bits.
The [U]ser List option in the User Maintenance routine has been changed to
[L]ist User file. The [U] option is now used for [U]pload Protocol.
Page 89
EchoDor Version 3.11
3/16/92
EchoDor now allows a user to upload a message. If the proper parameters
are specified in the EchoDor.Ctl file, EchoDor will ask the user if they
wist to upload a message. If they respond "Y", EchoDor will present the
protocols listed in the UPLOADFILE. It will then "switch" to the upload
and being the upload. When the upload is completed, EchoDor will import
the message (using word wrap mode), then switch to the editor so the user
can "taylor" the just uploaded message. The name of the file used for the
upload is not important
as EchoDor will import the first file it finds in the upload directory.
If a user was running a multiple zone setup, it became necessary to always
insert zone information in every message going out from EchoDor. EchoDor
will now watch for a multiple zone setup, if one is detected, EchoDor will
place an ^AINTL line in every net mail message. This function can also be
forced with a FORCEZONE command in the EchoDor.Ctl file.
3.10a revisions (we didn't release a 3.10):
When using EchoDor Nodelists, would not show the hub address.
Now does times read. This feature is integrated into the renumber/purge
utility so that it can tell you if an area has had NO activity.
Fixed, INCLUDE/EXCLUDE in EchoNLCP.
EchoNLRD can now read V6 node lists.
In some cases the NodeList search could go into a loop. Fixed.
When sending file attaches, EchoDor would only allow one file to be sent.
Now EchoDor will do a file search when using wildcards and will allow
multiple files to be specified. The length of the area that allows
specification has been increased to the full 72 characters. Also when
EchoDor did a file attach, the file name, exactly as entered, was placed in
the message. This would sometimes cause the mailer problems if it was in a
different directory. EchoDor now puts the file name complete with full path
and drive into the message.
When doing a message "Copy" EchoDor would say the wrong address, this has
been corrected.
After issuing a User or Packmail function you couldn't get the menu back
except with a question mark (?). This has been corrected so that if a
blank or null entry is made the menu will be re displayed.
If the time ran out during a full screen edit, the local screen went
strange. This has been corrected.
When packing or scanning and the user did not select All and EchoDor found
a private message addressed to the user or from the user or the user was a
sysop, EchoDor would display/pack the message (whew!) even if it did not
fit the requested criteria. Anyway, the scanning and packing is fixed so
they will work as expected.
Page 90
EchoDor Version 3.11
3/16/92
Removed the DISPLAY and DISPLAYLN functions from the CONFIG file. These
were causing problems with the various programs in EchoDor that have to use
this feature. Plus, future versions of EchoDor will not have need of these
options.
New read/pack/scan option, Mine. Allows reading/packing/scanning only
messages addressed to or from the user.
The user can now read messages during the scan procedure. All the user has
to do is enter the message number he/she wants to read and the message will
be displayed. After reading the message, the user can enter a new message,
reply to the message just read or return to the scan.
Once a user started packing mail, there was no way to stop it. Now, if the
user presses any key, EchoDor will ask if the user wants to stop.
Fixed overwrite problem by more prompt in help system.
Removed SYSOP lines from the EchoDor.Ctl file. This feature is now set
using the EchoUser program. If the user is logging on as a SYSOP with the
/S option, EchoDor will automatically give that person a SYSOP status.
Added user alias names. User alias names are automatically activiated when
one or more of the message bases allows aliases.
Added the ability to send anonymous messages.
Added a "MaxLineLength" option in the EchoDor.Ctl file. This option will
allow a sysop to force EchoDor to use a shorter line when reading and
entering messages. The MaxLineLength range is from 40 - 75. This option
is added to compensate for message editors that aren't smart enough to wrap
a quote. I sure wish some of the other authors would fix their "brain dead
editors"!
Visual edit will now show "Private" when entering a private message.
Added Read Help file. Enter "?" for help at the read menu. This is
currently (or should be if upgrading) set to EchoHLP4. This is the help
file that contains the read information. This file is set during startup
by a new EchoDor.Ctl command READHELPFILE.
When entering a message, EchoDor now allows the message attributes to be
altered. These attributes include Private, Crash, Hold, Return Request,
and Is Return. The attributes are changed using the Optn function.
EchoDor will now generate file update requests. If the netmail area allows
file requests, EchoDor will now ask File [R]equest / [A]ttach / [U]pdate.
When an update request is entered, EchoDor will change the name so that a
fill path name is used. EchoDor will also prevent wildcards from being
used with an Update request.
If EchoDor timed a user out the user record was not being updated. This
caused EchoDor to forget the last read pointers in the current area. This
has been corrected.
Page 91
EchoDor Version 3.11
3/16/92
When doing a message copy or a Xerox, EchoDor didn't clear the replyto and
next reply numbers. This would produce a strange effect when moved to a
different message area. Also, EchoDor didn't set the local flag. This is
corrected. Finally, if the message was private, that flag wasn't cleared.
The private flag is now cleared and if the target message area allows
private messages, EchoDor will ask if the message should be private.
The Visual Editor has an optional modified quote system. The old method
required two quote operations for the user to be able to insert quoted
lines into the message. If the new method is used (by placing NEWQUOTE in
the EchoDor.Ctl file), EchoDor will immediately insert the quoted lines
into the message ABOVE the cursor when the user exits quote mode.
EchoDor will now confirm when requesting to "kill" a message. An
additional Yes/No question is asked. This makes hot keys safer.
EchoDor will now confirm when requesting to "abort" a message after entry.
An additional Yes/No question is asked.
If a user is "deleted" using EchoUser, that user will no longer show up in
the "List user" functions.
EchoDor has a new read function, this is [F]ile. This allows a sysop to
save a message into a named file. When [F]ile is selected from the read
menu, EchoDor will request the file name. If the file already exists,
EchoDor will ask if you want to overwrite, append, or quit. If overwrite
is selected, EchoDor will overwrite the existing contents of the file, if
append is selected, the message is appended to the end of the file.
EchoDor would remove lines that began with Area: .. these types of lines
were generated by RAID. EchoDor is now smarter at removing lines that have
"key words" in them such as Area, Path, or SEEN-BY.
A problem was found in ECHONLCP which would cause it to put an incorrect
net number in node records when the node record immediately followed a ZONE
line without a REGION or HOST. This has been corrected.
EchoDor now supports Genesis Deluxe, GAP, OPUS 1.7x, and WildCat! version
3.0 bbs's. We no longer support OPUS 1.1x bbs's.
3.09 revisions:
EchoDor now has a "DIRECTVIDEO" option in the DoorDriv.Ctl file. This will
allow the sysop to configure EchoDor to either use BIOS writes (comment out
the DirectVideo line) or direct screen writes (include the DirectVideo
line).
A new parameter is now available in the EchoDor.Ctl file, this is the
"INCLUDE" parameter. This will be most used by sysops that run multiple
line systems and want to only maintain one file that contains the AREATABLE
and the AREADESC sections.
Page 92
EchoDor Version 3.11
3/16/92
EchoDor will now allow the SYSOP to configure HotKeys.
There was a problem in the origin net/node number when generating Echo
mail. This problem would cause UUCP not to function correctly with
messages generated by EchoDor. This has been corrected and UUCP should
work with EchoDor now.
I have included a little utility which will be useful for Opus Sysops that
want to use EchoDor. This is the OpusCnvt program. It will read
SYSTEM##.DAT files and create a file that contains AREATABLE/ENDAREATABLE &
AREADESC/ENDAREADESC sections. If this is used with the INCLUDE option,
conversion to EchoDor will be very fast.
Four new functions area available when selecting an area. These are the
[+]Next Area, [-]Prior area and the [>]Next Area with messages, [<]Prior
Area with messages functions. If the user selects "+", EchoDor will move
that user to the next area that he/she has set to active. When selecting
"-", the user will be moved to the prior area. If the user selects ">",
EchoDor will move to the next area that the user has set active which
contains unread messages. When selecting "<", EchoDor will move to the
prior area that the user has set active which contains unread messages.
Also, when changing areas with the plus and minus, EchoDor will tell you if
there are new messages in the area.
EchoDor now has "Hot Keys". When enabled the menu response is very fast.
In places where the user might need to type in multiple characters, the
"hot key" feature is disabled. I think you'll like this feature.
I have rewritten the Xerox function. The old function would only copy the
current message to the current area. The new Xerox function will now allow
the sysop to Xerox the current message to any area.
I have rewritten the sysop MESSAGE COPY function. The old function would
copy a message from any area to the current area. This would confuse some
people. The new MESSAGE COPY function will now allow you to copy a message
from any area to any area. The default is now from the current area to
another area which is the opposite of the old way.
There was a problem which would cause EchoDor to tell the user "You Don't
have enough time left" when he actually did. This problem was due to an
error in the MINTIME function. This has hopefully been corrected.
EchoDor will now tell you when you have exited chat mode. Prior to 3.09
you had to guess if you were still in chat after you pressed the ESC key.
In versions prior to 3.09 the "AutoMessage" function was only available if
you started EchoDor %1 /AUTO. Starting with this version, EchoDor will
always execute the "AutoMessage" function when it starts in normal mode.
This will allow a sysop to use the "AutoMessage" function without having to
run EchoDor twice.
EchoDor now has a [V]iew function available from the read menu. This
function is not listed on the read menu but is available to all SYSOPs.
The function allows a sysop to see all the ^A kludge lines, the SEEN-BYs,
Page 93
EchoDor Version 3.11
3/16/92
and the PATH lines. This is sometimes useful when trying to track where a
message has come from.
I have added a new option to the File function when importing files. This
function is [F]old lines. This option will retain the line structure, but
it will break the lines on word boundaries. This produces a much better
appearance than just importing the file.
When quoting with the full screen editor, EchoDor now removes all ^A,
SEEN-BY, and PATH lines from the message. Old versions prevented the user
from quoting the message but the new version removes the lines. This gives
the quote a "cleaner" appearance.
EchoDor now sets the "received" bit when a message is either read or packed
by the receiver. This is also displayed when reading the message and
scanning the message. EchoDor also increments the number of "times read"
counter in the message. This counter can be used to tell if an area is
active.
When a user first entered a message base and the first message was not 1 or
2, EchoDor would take a long time to read the first message. EchoDor now
keeps both a high message pointer and a low message pointer to an area.
This allows EchoDor to go immediately to the first message in an area.
Also, the first message number as displayed in the read menu correctly
reflects the first real message number.
The "Pack All Message Areas" question default has been changed from "Y" to
"N".
When packing a single area, the starting message number now defaults to the
last message read plus 1.
A problem was found which could cause EchoDor to lock up when packing mail
and the user dropped carrier. This problem has been corrected. Now when
packing mail, if the user drops carrier, EchoDor will exit normally.
EchoDor no longer contains the NODOORMODE parameter. When this parameter
was not present, EchoDor displayed it's name and a closing string when
exiting. The extra code has been removed along with the parameter.
EchoUtil had problems with most of the functions that used the "outbound"
area. Hopefully most of these problems have been corrected.
EchoUtil no longer contains the /SCAN and /DUMP functions. They have been
removed because of their size and because these functions are provided in
EchoDor.
EchoUtil can now process message areas that contain 5000 messages. This is
3000 more than prior versions.
If EchoUtil /M was run multiple time, it would increment the check messages
flag (asking the user to check for private messages) each time it was run.
This has been corrected. The counter will only be incremented once per run
per day.
Page 94
EchoDor Version 3.11
3/16/92
EchoUtil now has the /RENUM function. This will allow resetting the last
read pointers without deleting old users.
A problem was found in the EchoNLCP compiler. It would not write the last
block to the EchoDXID.IDX file. This would cause EchoDor not to be able to
find the last 1000 nodes in the nodelist file. This problem has been
corrected.
EchoNLCP will now skip files that have an extension of DAT, IDX or FDX.
Node list files must never have this extension.
EchoNLRD has been enhanced to allow node list searching. This is identical
to the operation of the node list option in EchoDor.
A new program called EchoUser is now available. This allows you to set
individual usre's security and access levels as well as more precisely
control new user access. This program will run either remote or local.
3.08 revisions:
EchoDor now has new commands in the read menu to allow the user to read a
thread. These new commands are plus (+), minus (-), and asterisk (*).
Users can now enter messages from the Read menu by pressing the letter "E"
for enter. Because this was the old EDIT command, the new command to
replace edit is CHANGE which uses the "C" key.
The "Doctor" command now understands all the "bits" in a message. This has
required some changes in the layout but it should present no problems.
EchoDor.Ctl file has been slightly altered. This alteration allows EchoDor
to load the file more quickly. See UPDATE.DOC on how to change your file
to the new format.
Some commands have also been eliminated from the EchoDor.Ctl file. These
commands were duplicates of commands already in the DoorDriv.Ctl file.
These commands DO effect the display color. Be sure to read UPDATE.DOC on
setting new colors.
New NodeList format. Starting with 3.08 of EchoDor, a special format
Nodelist can be used in place of the version 6 nodelist required by prior
versions. This new nodelist uses a set of index files to allow use of the
RAW nodelist file. This will reduce the amount of disk space required to
support EchoDor. (A full nodelist required about 180k plus the raw
nodelist file). People running FrontDoor and D'Bridge will gain the most
from this feature. Note: Although the unregistered version of EchoDor
supports this new nodelist format the compiler which is required to
generate these files is included ONLY IN THE REGISTERED VERSION.
There are some slight changes in the user interface which should make
EchoDor easer to use.
The [P]ack Mail feature now allows the user to select the type of
compression to use to compress the mail files.
Page 95
EchoDor Version 3.11
3/16/92
There were also problems when returning to EchoDor from [P]acking mail.
These problems have been corrected.
EchoDor now inserts the new ^AMSGTO: line into outbound messages.
The number of lines allowed in a message has been increased from 200 to
512.
When displaying a node list entry from the sysop menu, EchoDor now displays
the baud rate of the BBS.
EchoDor had a problem displaying node list information which contained a
password that was 8 characters long. This has been corrected.
Long messages would sometime cause EchoDor a run time error. This has been
corrected. Now EchoDor will truncate the message to a maximum of 512
lines.
EchoDor would always attempt to verify a user when entering into the local
message base even if the message wasn't private. This has been corrected
so that EchoDor will only verify private messages.
EchoDor can now import files when entering messages. This feature is only
available when running in local mode.
The "read lock" from value could not be set. This has been corrected.
The arrow keys on remote systems should now work correctly. Prior to
version 3.08, EchoDor would have problems with the special character keys
(arrow and such) from slow modems. This has hopefully been corrected.
When copying a message EchoDor would not insert the "message copied from"
information. This has been corrected.
EchoDor had a problem when users returned from a download (using the
EchoDor %1 /R line). Sometimes it would reset the time back to when they
first entered the door, other times it would just forget who was online.
This has hopefully been corrected. I have been doing a lot of testing in
this area and have not seen the problem with this version.
Page 96
EchoDor Version 3.11
3/16/92
Run Time Errors
From time to time EchoDor or one of the support programs may run into
problems and generate a "run time" error. The following table lists errors
and possible causes:
Error 001
Invalid function number
This can occur if your running an older version of DOS. All versions
of EchoDor and it's utilities require DOS 3.0 or greater.
Error 002
File not found
This is a file not found error. If you get this first try running
CheckOut and see if it identifies any missing files. If no errors are
reported by CheckOut, look through your EchoDor.Ctl file and check the
file names on the parameters that have file names.
Error 003
Path not found
This is a path not found error. This is very much like the file not
found error above except this error indicates that a directory that
you have referenced does not exist. Correct this error like your
correcting an 002 error.
Error 004
Too many files open
This is the "too many files open" error. This will occur if your
FILES=xx in your CONFIG.SYS file isn't big enough. The xx should be
at least 20.
Error 005
File access denied
This is a file access denied message. If you receive this please try
to reproduce it. If you can reproduce it, please notify me so that I
can fix the problem.
Error 006
Invalid file handle
Page 97
EchoDor Version 3.11
3/16/92
This is an invalid file handle error. First try to recopy EchoDor.EXE
(or whichever program gave you the error) from your original release
back to your disk drive. If you receive this error again, please
notify me. Have you EchoDor.Ctl file and your DoorDriv.Ctl file
available when you call.
Error 012
Invalid file access code
This error indicates an access error. First try to recopy EchoDor.EXE
(or whichever program gave you the error) from your original release
back to your disk drive. If you receive this error again, please
notify me. Have your EchoDor.Ctl file and your DoorDriv.Ctl file
available when you call.
Error 015
Invalid drive number
This error is only reported by MkDir or ChDir. There is no MkDir or
ChDir in EchoDor. First try to recopy EchoDor.EXE (or whichever
program gave you the error) from your original release back to your
disk drive. If you receive this error again, please notify me. Have
your EchoDor.Ctl file and your DoorDriv.Ctl file available when you
call.
Error 016
Cannot remove current directory
This error is only reported by RmDir. There is no RmDir in EchoDor.
First try to recopy EchoDor.EXE (or whichever program gave you the
error) from your original release back to your disk drive. If you
receive this error again, please notify me. Have your EchoDor.Ctl
file and your DoorDriv.Ctl file available when you call.
Error 017
Cannot rename across drives
This error is only reported by Rename. There is no "Rename" in
EchoDor. First try to recopy EchoDor.EXE (or whichever program gave
you the error) from your original release back to your disk drive. If
you receive this error again, please notify me. Have your EchoDor.Ctl
file and your DoorDriv.Ctl file available when you call.
Error 100
Disk read error
This will generally indicate some sort of disk problem. To quickly
check to see if the error is caused by a problem with one of the
EchoDor files ... get to dos and switch to the EchoDor directory.
Then attempt to copy all the files to the nul device:
Page 98
EchoDor Version 3.11
3/16/92
COPY *.* NUL
This will cause DOS to read each of the files but the copy will not
put them anywhere. If you get an error during the copy, replace the
file that copy indicates is in error and try the copy again. If you
don't get an error when you do this, check your message base. Go to
the message area that the user was in when the error occured and try
the above copy in that directory. If a #.msg file is found to be in
error, delete the file. If no errors are still found, you may want to
run a utility like NDD (Norton Disk Doctor) or DISKFIX (from
PC-Tools).
Error 101
Disk write error
This indicates some sort of disk problem. First check to make sure
your not out of disk space. Check both the drive that the message
base is on and the drive that EchoDor is on (if different). If you
have sufficient space, you may want to run a utility like NDD (Norton
Disk Doctor) or DISKFIX (from PC-Tools).
Error 102
File not assigned
This error could indicate a program problem. First recopy EchoDor.EXE
(or whichever program gave you the error) from your original release.
If you still get the error, please notify me. Have your EchoDor.Ctl
and your DoorDriv.Ctl files available when you call.
Error 103
File not open
This error could indicate a program problem. First recopy EchoDor.EXE
(or whichever program gave you the error) from your original release.
If you still get the error, please notify me. Have your EchoDor.Ctl
and your DoorDriv.Ctl files available when you call.
Error 104
File not open for input
This error could indicate a program problem. First recopy EchoDor.EXE
(or whichever program gave you the error) from your original release.
If you still get the error, please notify me. Have your EchoDor.Ctl
and your DoorDriv.Ctl files available when you call.
Error 105
File not open for output
Page 99
EchoDor Version 3.11
3/16/92
This error could indicate a program problem. First recopy EchoDor.EXE
(or whichever program gave you the error) from your original release.
If you still get the error, please notify me. Have your EchoDor.Ctl
and your DoorDriv.Ctl files available when you call.
Error 106
Invalid numeric format
This error could indicate a program problem. First recopy EchoDor.EXE
(or whichever program gave you the error) from your original release.
If you still get the error, please notify me. Have your EchoDor.Ctl
and your DoorDriv.Ctl files available when you call.
Error 150
Disk is write protected
This indicates a write protected disk. If your running from floppies,
check to make sure there is no write protect tab on the disk. If your
running from hard disk, first try a reboot. If the problem occurs
again try copying EchoDor.EXE (or whichever program gave you the
error) from your original release. If the problem still occurs,
please call me and have a copy of your EchoDor.Ctl and your
DoorDriv.Ctl files available.
Error 151
Unknown unit
This indicates DOS could not find a specified unit. First try a
reboot. If the problem occurs again try copying EchoDor.EXE (or
whichever program gave you the error) from your original release. If
the problem still occurs, please call me and have a copy of your
EchoDor.Ctl and your DoorDriv.Ctl files available.
Error 152
Drive not ready
This indicates a specified drive was not ready. First try a reboot.
If the problem occurs again try copying EchoDor.EXE (or whichever
program gave you the error) from your original release. If the
problem still occurs, you may want to run a utility like NDD (Norton
Disk Doctor) or DISKFIX (from PC-Tools).
Error 153
Unknown command
This indicates a drive did not understand what DOS wanted the drive to
do. First try a reboot. If the problem occurs again try copying
EchoDor.EXE (or whichever program gave you the error) from your
original release. If the problem still occurs, you may want to run a
utility like NDD (Norton Disk Doctor) or DISKFIX (from PC-Tools).
Page 100
EchoDor Version 3.11
3/16/92
Error 154
CRC error in data
This indicates a problem exists when trying to read data from a file.
First try the procedure outlined for Error 100. If that dose not
work, try reinstalling EchoDor.
Error 155
Bad drive request structure lenght
This is an internal DOS error. First try a reboot. If the problem
occurs again try copying EchoDor.EXE (or whichever program gave you
the error) from your original release. If the problem still occurs,
you may want to run a utility like NDD (Norton Disk Doctor) or DISKFIX
(from PC-Tools).
Error 156
Disk Seek error
This is a disk problem. First try a reboot. If the problem occurs
again try copying EchoDor.EXE (or whichever program gave you the
error) from your original release. If the problem still occurs, you
may want to run a utility like NDD (Norton Disk Doctor) or DISKFIX
(from PC-Tools).
Error 157
Unknown media type
This is a disk problem. If your running from diskette, try using
another formatted diskette. If your running from a hard disk try a
reboot. If the problem occurs again try copying EchoDor.EXE (or
whichever program gave you the error) from your original release. If
the problem still occurs, you may want to run a utility like NDD
(Norton Disk Doctor) or DISKFIX (from PC-Tools).
Error 158
Sector not found
This is a disk problem. If your running from diskette, try using
another formatted diskette. If your running from a hard disk try a
reboot. If the problem occurs again try copying EchoDor.EXE (or
whichever program gave you the error) from your original release. If
the problem still occurs, you may want to run a utility like NDD
(Norton Disk Doctor) or DISKFIX (from PC-Tools).
Error 159
Printer out of paper
Page 101
EchoDor Version 3.11
3/16/92
This will only happen if you try to do an HCOPY and your printer is
out of paper. Correct the problem and try again.
Error 160
Device write fault
An error occurred while trying to write to the disk or printer or
screen. First try a reboot. If the problem occurs again try copying
a new copy of EchoDor.EXE (or whichever program gave you the error)
from your origional release. If the problem still occurs, you may
want to run a utility like NDD (Norton Disk Doctor) or DISKFIX (from
PC-Tools).
Error 161
Device read fault
An error occurred while trying to write to a device. Correct as for
Error 160.
Error 162
Hardware failure
This is a general hardware failure. If this occurs try First try a
reboot. If the problem occurs again try copying a new copy of
EchoDor.EXE (or whichever program gave you the error) from your
origional release. If the problem still occurs, you may want to run a
utility like NDD (Norton Disk Doctor) or DISKFIX (from PC-Tools). If
it still occurs, you may need service.
Errors 200-214
This error could indicate a program problem. First recopy EchoDor.EXE
(or whichever program gave you the error) from your original release.
If you still get the error, please notify me. Have your EchoDor.Ctl
and your DoorDriv.Ctl files available when you call.
Page 102
EchoDor Version 3.11
3/16/92
Plans for next version
Further ability in the EchoNLCP compiler.
UNIX e-mail and news group support. With this addition EchoDor will
understand how to write message to be understood by UUCP.
Time estimates for downloads.
Page 103
EchoDor Version 3.11
3/16/92
Registration
EchoDor represents MANY hours of work and if you find it useful, I would
appreciate your sending in a donation of $25 or more. I will send you back
a DSDD 5.25" disk or a 3.5" disk with a registration key and perhaps a few
other small utilities that will fit on it. This registration key can be
used with the current and all future releases of EchoDor.
My mailing address is:
Robert McCullough
P.O. Box 101095
Nashville, TN 37224-1095
My voice telephone number is:
615 256-2444
If your going to call me, please remember that I live in the central
time zone.
When you register, please send me you name, address, voice phone, BBS name,
BBS type, BBS phone, and where you got EchoDor. Also, if you send me
either a FidoNet or RBBSNet node number, I can send you the key via net
mail.
I'd like to thank the people that have supported EchoDor through their
registration. I will continue to support the users of EchoDor in a
professional maner and will hope to receive your support in return.
Also, if you use RASMAM be sure to follow the authors registration
requirements. Registration of EchoDor does NOT give you a registration to
RASMAM.
Page 104
EchoDor Version 3.11
3/16/92
Disclaimer
This program is being distributed under the following conditions:
1. This code or any of the files associated with it may not be
distributed in modified form in any way. You may archive this program
and it's associated files in any manor that is suitable for your BBS.
Please do not delete any files from the archive.
2. You may not use any portion of the code distributed with this package
in any other program without my written permission.
3. This software and/or code may not be distributed for a profit. This
does not exclude the archive from being on a pay for use BBS.
4. I am in no way responsible for any damage that may be caused due to
the use or misuse of this software. The user assumes all
responsibility for any damages and holds the author harmless.
Page 105
EchoDor Version 3.11
3/16/92
Guarantee
There is absolutely no guarantee, warranty or promise of any kind made
with regard to the performance or quality of the EchoDor software,
utilities, documentation, or any associated files. Any problems,
risks, damages, disasters or lack of them are purely you're
responsibility. By using this software, documentation, utilities, or
any associated materials, you acknowledge this in full.
Page 106